dhis2-devs team mailing list archive

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

I am not sure what the source of the ambiguity actually is. A given data
element is linked to a single option set (at least currently).  Since every
data value is tied to a data element and the data element is in turn linked
to an option set, I am not sure what the source of the ambiguity is?

I think there are good analytical reasons not to make this unique. You may
want to have an option set like

Option = "Yes", "No"
 Code = "1", "0"

Option "TRUE", "FALSE"
Code = "1", "0"

>From the current analytics, it makes things easier when it comes to
aggregation but might make more sense from data entry perspective to have
both option sets.

I would suggest you setup your own restriction on this in your database by
adding an SQL integrity check which you can use to identify and test
against. Maybe something like:



sierra-leone=#  SELECT code,COUNT(*) FROM optionset GROUP BY code HAVING
COUNT(*) > 1;
 code | count
------+-------
      |   114
(1 row)

Regards,
Jason



On Sat, May 6, 2017 at 10:57 AM, Busoye Anifalaje <busoye@xxxxxxxxxxxxxx>
wrote:

> Hi Jhansi,
>
> Your second suggestion is a good one with slight modification: introduce a
> setting for the option set to enforce unique option codes. This makes it
> optional per option set. The reason for this is that there are use cases
> where the option code is used as a value for example If the option set are
> possible answers to a question. The right answer (option) may have a code
> of 1 while all the alternative options will be assigned 0. In this case it
> is not essential to distinguish between the options just that one option
> was right while the rest were wrong.
>
> If the devs go ahead with your second suggestion, they will be introducing
> another problem. So making uniqueness of option codes optional would
> provide a more robust solution and flexibility.
>
> Cheers.
>
> - -
>
>
>
> *Busoye Anifalaje (PhD)*
> Director of Services (Principal), BAO Systems
> UK: +44 7901-740-757 | US: +1 682-307-0986|
>  busoye@xxxxxxxxxxxxxx | http://www.baosystems.com |
> Skype: busoye | 2900 K Street, Suite 406, Washington D.C. 20007
>
> On 6 May 2017, at 09:47, jhansirk <jhansirk@xxxxxxxxxxxxxxxx> wrote:
>
> Hello DHIS Devs,
>
> In DHIS, event capture app while registering an event, we have noticed
> that the event dataValues (for the dataElements with optionSet) are posted
> with the selected option code. Similarly, in the event list the event data
> values are mapped with the option code to show the selected option.
>
> We see a small problem with this approach, since, option code in option is
> not a unique value, which means there is a possibility of two options
> having the same option code leading to ambiguity in finding the selected
> option.
>
> Instead, we think it should be either of these two:
> - In Event capture, event data values should be saved with some unique
> option property (like option id) instead of option code. But, this would be
> a very huge migration, since, all the existing event data values should be
> changed from option code to option id.
> - In Option, code should be made unique and there should be validations in
> option creation form to ensure option code is unique. This would be the
> simpler change to implement and our preferred solution to this issue.
>
> Thanks,
> Jhansi
> _______________________________________________
> 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
>
>


-- 
Jason P. Pickering
email: jason.p.pickering@xxxxxxxxx
tel:+46764147049