Oops .. Just spotted a method in categoryservice ... hold on.
On 8 February 2012 15:25, Bob Jolliffe wrote:
> I have a "small" problem to which I am seeking advice.
>
> Currently we store dimensions of data collapsed into a
> categoryoptioncombo. Which we are not particularly fond of but we
> have a lot built on top of it and so we learn to live with it.
>
> When reading in data from elsewhere (mobile, 3rd party or fellow dhis
> system) we either will see the data dimensions explicitly (Sex='Male',
> Age='<5') or we will see a categoryoptioncombo from another dhis2
> instance. Either way the task is to efficiently find the
> categoryoptioncombo in the receiving system to store the datavalue
> against. I have been a bit preoccupied with the first case, but it
> seems the second case leads to a similar lookup problem if we want to
> import data without simultaneously also importing the foreign metadata
> which we do.
>
> Example snippet from dxf1 metadata:
>
> 834
>
> 824
> Age+Gender
>
>
>
> 802
> >=50
>
>
> 822
> Female
>
>
>
>
> We can see the categoryoptioncombo on the sending system is 834. But
> we want to map this to a corresponding categoryoptioncombo on the
> receiving system eg. 834->76. The two most important bits of
> information we have to go on are the two categoryoption names. So in
> that sense this is not fundamentally different from the case of
> explicit dimensions. The categoryoptioncombo must be some function of
> these two names. Currently we have no obvious service method which
> will take a list of categoryoptions and return a categoryoptioncombo.
> Something along the lines of:
>
> CategoryOptionCombo getCatOptComboByCatOpts(Collection
> catopts)
>
> We need something like this but the question is how to do it
> efficiently - I can't see a clean sql query but maybe Jason can :-)
> Unlike other dhis2 metadata we don't persist the name with
> categoryoptioncombos otherwise we could use this.
>
> Using the categoryCombo might help to restrict the scope of query or
> may add additional complexity. I'm not sure.
>
> If the sending system were to use the stable uids of the receiving
> system, the problem is solved for dhis2 to dhis2 but still remains for
> external data.
>
> Any suggestions as to the best way to approach this? It is tempting
> to look at the _categoryoptioncomboname "resource" table but this is
> not guaranteed to be available. There is certainly nothing impossible
> about it, but also no particularly clean way to do it.
>
> Cheers
> Bob
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp