Hi Mansi,
it’s a good question and there is no doubt that the names should be stable.
The reason we haven’t used a list is simply due to complexity of the business logic. Like Jason says, the option combo name ordering should not be alphabetical, rather according to the order of the categories in category combination linked to the category option combination (read twice;).
So if the category combination ccA has categories cB and cA in that order with options respectively coB and coA, then a category option combination should have the name “coB, coA”, not “coA, coB” (alphabetical).
Every time a user changes a category combination, the order of categories, removes/adds categories, removes category options etc then we need to update and validate all category option combinations for that category combination (checking if some must be added, removed). And if we introduce a List for the category option combination > category option association, we need to check the order as well and potential shuffle it. This adds complexity and takes more time.
So agree that is could be improved but its a bit more challenging that just changing the collection type 
We can look into it together after 2.16 if you want.
cheers
Lars
···
On Fri, Jul 18, 2014 at 8:33 AM, Jason Pickering jason.p.pickering@gmail.com wrote:
I think this has been discussed before, and I would be in favor of being able to get reproducible names. However ideally, I think it should be up to the implementer to determine this. So, lets say you have a category (B,A) and age groups (Y,X,Z). So, the user would then get the following category combo options
B,Y
B,X
B,Z
A,Y
A,X
A,Z
So, the ordering of the category options should be the same as when the category is created and sorted by the user, not necessarily by alphabetical order.
Best regards,
Jason
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
On Fri, Jul 18, 2014 at 8:02 AM, Mansi Singhal msinghal@thoughtworks.com wrote:
Hi Lars/Morten,
Can you please let us know your suggestions on the same?
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
On Wed, Jul 16, 2014 at 2:57 PM, Mansi Singhal msinghal@thoughtworks.com wrote:
Hi Morten,
Thanks for the quick reply.
We saw the code. It is getting the names of category options in a HashSet and generating the names iterating over it. We get different names since HashSet is not ordered.
Would it be a good idea to return the exact same response each time for the same query parameter? We can do this by converting the Set to a List and sorting it alphabetically. Let us know what you think. If you are ok with this approach, we would like to submit a patch for it.
Regards,
Mansi Singhal
–
Thanks,
Mansi
On Wed, Jul 16, 2014 at 2:22 PM, Morten Olav Hansen mortenoh@gmail.com wrote:
Hi Mansi,
Names for DataElementCategoryOptionCombo are not persisted, but rather generated on the fly. Please have a look at DataElementCategoryOptionCombo.getName.
I don’t know exactly why this is, I will let Lars add to it.
–
Morten
On Wed, Jul 16, 2014 at 3:41 PM, Mansi Singhal msinghal@thoughtworks.com wrote:
Hi,
We are creating category option combos by posting the following JSON to /api/metadata.
{
“categoryOptionCombos”: [{
“id”: “cdf922cc47b”,
“categoryCombo”: {
“name”: “A and B”,
“id”: “abe84f2cf8e”
},
“name”: “(abc, def)”,
“categoryOptions”: [{
“id”: “z2ab39bcfd7”,
“name”: “abc”
}, {
“id”: “c78bd47f6af”,
“name”: “def”
}]
}]
}
When we are trying to GET the category option combos using /api/categoryOptionCombos, the name we get is inconsistent with every call. We are getting (abc, def) for some times and (def, abc) some other times.
Is this the intended behavior? Shouldn’t the name retrieved be the same as the name POSTed as is the case for every other metadata?
–
Regards,
Mansi Singhal