dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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@xxxxxxxxx> 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@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
>>>
>