dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 19 February 2013 19:54, Jason Pickering <jason.p.pickering@xxxxxxxxx> wrote:
> Hi Bob,
>
> I am still not sure I get what you mean about the category option combo
> name. What would be the point of defining it? I though the whole purpose was
> to ease this process, so we did not have to define a name for each and every
> category option combo?

My point was about the table structures.  The designers obviously
thought as you are thinking now.  No need for a persisted name.  Its
just going to be auto-generated from the categoryoptions anyway
(albeit currently in random order).

BUT ...

It was later discovered, probably when making pivot table views for
Excel would be my guess, that in fact a persisted name is quite handy
- many times easier than doing the sql equivalent of what is is done
in java to produce "(Male,<1)" (or "(<1,Male)" ).  So we created the
_catoptcomboname table.  That's the bit I never understood ie. why not
just add a name field to the catoptcombo table and be done?  And
populate that (automatically) at the time that the catoptcombo is
being created/persisted.  Creating a whole new resource table just for
this doesn't make much sense.   If we don't want to store redundant
stuff on the object, maybe adding name to the _categorystructure table
would have sufficed.  Anyway that is all aesthetics and a bit removed
from your actual problem.

> Otherwise, we could go back to 1.4 style default data elements, and simply
> put the name there.  I guess I may still be missing your point, but the
> relevant observation from Nigeria is below.
>
>  I think what you suggest is what we would like to see.
>
> For the M&E people,
>
> (Male, <1 year) and (<1 year, Male) does not necessarily seem to be how they
> want to see it.
>
> So, ordering of the categories within the combo, and then the options in the
> categories should be respected when it comes to naming them. So if the order
> in the cat combo is (Gender, Age) then the gender should always come before
> age in the cat option combo.

Agree.

> I tried but failed to unwind this to reconstruct the names through SQL, so
> may have to have a look in that class to see how it is done. Does not really
> matter though, as there is no way to predict which order the names will come
> out anyway currently, if we want to attempt to match something on them.

Currently the class just concatenates the relevant catopts together in
whatever order they come out.  And is conceivable they can come out
differently.  Particularly if you done something structurally
significant which *might* reverse the order, like perhaps exporting
and importing into a new database.  I think this bit could be fixed
easy enough to make it deterministic based on the category sort order.
 I'll check later.

Though you also have another requirement which is similar sounding but
not really related to this one ... you also want a sort order on the
categoryoptioncombos (autogenerated from the underlying sort orders).
I can see the sense in that, but also suspecting its a bit more work
than the other thing related just to the order within the names.  In
fact this one does strike me as maybe a good candidate for something
like the _categorystructure table.

Bob

>
> Regards,
> Jason
>
>
>
> On Tue, Feb 19, 2013 at 1:23 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>>
>> 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
>> >>>
>> >
>
>