Reading back through my comment I don’t understand it either. If it
helps, when I said "I don’t really understand why the ‘name’ field
isn’t just part of the categoryoption" I meant the
categoryoptioncombo, not the categoryoption. I think our model jars a
bit here where the categoryoptioncombo table doesn’t have a name
field. I guess because the whole model was geared towards form input,
and there was no need to name the categoryoptioncombo on a form. But
people found it useful in reporting, so it was added as an
afterthought via the _categoryoptioncomboname table. (still don’t see
why a name field wasn’t just added instead but I wasn’t there).
But this doesn’t sound like it should be difficult to fix in its
present form. The code for DataElementCategoryOptionCombo.getName()
is used to generate the name for the resource tables. And as far as I
can see this code doesn’t take the ordering of categories into
account. In fact the code for equalsOnName() in the same class is
made quite complicated as a result as it explicitly assumes that the
name is effectively an unordered Set of option names.
So what we’d like to see is that for a given categorycombo with a
given sortorder, the getName() method of all categoryoptioncombos
belonging to that categorycombo will always compose the name according
to the sort order of the categorycombo?
(Bit of a mouthful that. And can I have it with chips please.)
Bob
On 19 February 2013 05:08, Jason Pickering jason.p.pickering@gmail.com wrote:
Yes, that I know. That is not the issue at hand. The issue is how they
actually come out in the resource tables, and whether or not the order name
in the resource table should match that of the ordering of 1) Categories and
then 2) Category options within the categories.
I was able to reproduce the random ordering in the resource table several
times, and considering this may be used in other things (reports), sometimes
you may get (Male ,<1) and another time (<1, Male) . Of course this is the
same thing to some people., but it seems it is not the same thing to the M&E
people who brought my attention to it.
Dunno about this one, but I think the random ordering of them is not the
right behavior, as it is unpredictable.
Not really sure if I understand Bob’s comment, but that sure would make it
much much easier to attempt to unwind this part of the data model through
SQL (if it is even possible).
Regards,
Jason
On Tue, Feb 19, 2013 at 2:55 AM, Ola Hodne Titlestad olati@ifi.uio.no
wrote:
The order is used in data entry.
Ola
On 18 Feb 2013 15:25, “Jason Pickering” jason.p.pickering@gmail.com
wrote:
I guess I would have expected the sort order of the category options and
categories to do something, but it appears they do not. Will try and unwind
the data model and see if I can get out what I want, but I think in general,
the ordering of the categories (within a category combo) and the ordering of
the options (within a category) would seem to make sense, otherwise, there
is really no need for people to try and order them as they want.
Regards,
Jason
On Mon, Feb 18, 2013 at 5:32 PM, Bob Jolliffe bobjolliffe@gmail.com
wrote:
Don’t know if its just me, but I’ve always felt the
_categoryoptioncomboname table is itself a bit of a bug. I don’t
really understand why the ‘name’ field isn’t just part of the
categoryoption. Which is generated when the categoryoptioncombo is
created. But no doubt there is some legacy rationale why it was done
this way.
The name in itself is an unreliable thing to match against. I think
the only reliable matching would be against the underlying categories
and their options. Of course the name can be useful to unravel
these, but probably “easier” to look at the relations
(categoryoptioncombos_categoryoptions).
On 18 February 2013 15:01, Jason Pickering jason.p.pickering@gmail.com
wrote:
Dear Devs,
I have run up against a strange issue. We are currently in the process
of
transforming a lot of data elements from non-dimensional data elements
to
ones with categories combos. We have previously done a large matching
exercise for this. I could not figure out why the names were not
matching,
as we were pretty scrupulous. But, as it turns out, DHIS2 changes the
names
when the resource tables are regenerated. The order which is present
in the
category combo, does not seem to be respected.
This is the result of two SQL queries.
- Before running the resource tables.
SELECT * FROM _categoryoptioncomboname where categoryoptioncomboname
~*('FP
Site’)
448577;“(20-24, FP Site, Male)”
448588;“(FP Site, Female, 25-49)”
448596;“(FP Site, 50+, Female)”
448607;“(FP Site)”
…
- Immediately after resource table regeneration.
SELECT * FROM _categoryoptioncomboname where categoryoptioncomboname
~*('FP
Site’)
448577;“(FP Site, 20-24, Male)”
448588;“(FP Site, Female, 25-49)”
448596;“(FP Site, 50+, Female)”
448607;“(FP Site)”
…
Note that the category options are the same, but they order is
different.
Is this a bug, or are the category names ephemeral?
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
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