dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Oops .. Just spotted a method in categoryservice ... hold on.

On 8 February 2012 15:25, Bob Jolliffe <bobjolliffe@xxxxxxxxx> 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:
> <categoryOptionCombo>
>            <id>834</id>
>            <categoryCombo>
>                <id>824</id>
>                <name>Age+Gender</name>
>            </categoryCombo>
>            <categoryOptions>
>                <categoryOption>
>                    <id>802</id>
>                    <name>&gt;=50</name>
>                </categoryOption>
>                <categoryOption>
>                    <id>822</id>
>                    <name>Female</name>
>                </categoryOption>
>            </categoryOptions>
>        </categoryOptionCombo>
>
> 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<CategoryOption> 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