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>>=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