dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

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@xxxxxxxxxx>wrote:

> The order is used in data entry.
>
> Ola
> -------
> On 18 Feb 2013 15:25, "Jason Pickering" <jason.p.pickering@xxxxxxxxx>
> 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@xxxxxxxxx>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@xxxxxxxxx>
>>> 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.
>>> >
>>> > 1) 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)"
>>> > ...
>>> >
>>> > 2) 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@xxxxxxxxxxxxxxxxxxx
>>> > Unsubscribe : https://launchpad.net/~dhis2-devs
>>> > More help   : https://help.launchpad.net/ListHelp
>>> >
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>>