dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #02864
Re: [Branch ~dhis2-devs-core/dhis2/trunk] Rev 938: Made the uniqueness constraint on CategoryOption back in. Will maintain it in a transition period.
OK, I took a walk around the block to think about this a bit more. I
think it does, make sense, sort of. Lets look at "Total", which might
be defined as a calculated data element, say composed of different age
groups. But the "Total" in this category, would not be the same as the
"Total" that might be defined in a different category, or would it?
Having a single categoryoption "Total" would allow one to slice out
particular groups of dimensional elements, which is a fairly common
operation as Ola mentions, with a single filter statement. Otherwise,
you would need to collect all of the "Total"s for different categories
through another table and perform an inner join, as opposed to a
filter. For multiple category options, I guess there would need to be
a decision made whether to perform an inner join or loop through a
filter, but I guess an inner join would actually be better for either
one or many category options (have not looked at the code). If the
uniqueness contraint is not there, the user would need to select in a
separate step to select all "Total"s and then perform an inner join,
as there would be no intrinsic relationship between "Total" in the
"Age" category and the "Total" in the "Gender" category. This might be
very tedious if there are many categories to select from. Having
multiple category options with the same name does not make sense in
this case, and I think this is what everyone is saying?
Obviously there should not be two category options called "Total" to
be within a single category/data element group set. However,I am not
sure I understand completely your point Ola. To me, the use case you
describe is very typical. "Give me all data for the under 1 age
group", "Give me all data on in patient discharges". Having to define
multiple "under 1" and "IPD" for each category seems to be very
inefficient, as well as painful.
So, I guess maybe I am answering my own mail...I think.
2009/10/30 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>
>
> On Fri, Oct 30, 2009 at 2:43 PM, Jason Pickering
> <jason.p.pickering@xxxxxxxxx> wrote:
>>
>> Could some one remind me once again what the point of having a
>> category option in two separate categories is? is there a use case
>> here? It does not seem totally obvious, but maybe I am missing
>> something.
>>
>
> It might be that there are none. This could be useful in the sense that if
> nobody asks for removing the constraint - we won't.
>
>
>
Follow ups
References