dhis2-devs team mailing list archive

[Olav Poppe <olav.poppe@xxxxxx>]

Hi, 
I might have misunderstood both the issue and your example, Jason, but my understanding was that the problem here is that duplicate codes within an option set is allowed, while your example refer to options having the same codes in different option sets?

I would in any case argue for having at least an option for checking for uniqueness of codes within an option set, so that the selections from data entry is stored. I actually thought that was the case already (I think it was at some point?), but noticed last week that it isn’t in 2.26 at least, and I’ve been meaning to write to the list for clarification.

Olav




> 6. mai 2017 kl. 11.33 skrev 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 <mailto: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.
> 
> - -
> 
> <Screen Shot 2017-03-01 at 15.10.20.png>
> 
> 
> Busoye Anifalaje (PhD)
> Director of Services (Principal), BAO Systems
> UK: +44 7901-740-757 | US: +1 682-307-0986|
>  busoye@xxxxxxxxxxxxxx <mailto:busoye@xxxxxxxxxxxxxx> | http://www.baosystems.com <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 <mailto: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 <https://launchpad.net/~dhis2-devs>
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx <mailto:dhis2-devs@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~dhis2-devs <https://launchpad.net/~dhis2-devs>
>> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs <https://launchpad.net/~dhis2-devs>
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx <mailto:dhis2-devs@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~dhis2-devs <https://launchpad.net/~dhis2-devs>
> More help   : https://help.launchpad.net/ListHelp <https://help.launchpad.net/ListHelp>
> 
> 
> 
> 
> -- 
> Jason P. Pickering
> email: jason.p.pickering@xxxxxxxxx <mailto:jason.p.pickering@xxxxxxxxx>
> tel:+46764147049
> _______________________________________________
> 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