dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #14045
fixing what's broke without breaking what's fixed - categoryoptioncombos
I've a problem which I'd welcome some input on. And which is at least
peripherally related to the mail Knut has just sent re case sensitive
name matching (MALE != Male).
Its about fixing the categoryoptioncombos and bringing in the notion
of concepts, which has already been discussed at length elsewhere and
is blueprinted and tagged here:
https://blueprints.launchpad.net/dhis2/+spec/extend-category-and-groupsets-model-with-concepts
Whereas implementing this is fairly straightforward I'm a bit unsure
how to manage the updating of existing databases which have already
built up an impressive array of aliases for things like '<5'.
One aim is to get rid of, or rather merge, categoryoptions like "<5",
" <5", "HIV_under5", "TB_under5" etc. Currently we know these things
are there because of the problem that categoryoptions must be unique
and cannot appear in more than one category, causing implementors to
invent various ways of saying under 5.
The proposal to fix this is to have a single categoryoption '<5' with
a concept AGE and various categories with concept AGE (ie various
lists of age groups, but drawing from the same pool of options with
concept AGE). This should work well and will cause no problems with
new databases and in the absence of any existing datavalues. But ....
the problem I see is that it is going to be quite difficult to make
these adjustments and mergers on a live database with existing
datavalues mapped to existing categorycombos. ie. repairing the
damage of the past 12 months.
Imagine I have 2 dataelements, de1 with category HIV_age which
includes the option HIV_under5, and de2 with category Malaria_age
which includes the categoryoption 'Malaria_under5'. Basically I want
to be able to merge "HIV_under5" with "Malaria_under5" to just create
"under5". Then we are back to some form of sanity. And worse, I need
users to be able to do this - it can't be doe automatically. The
problem is that to do this will require quite a significant amount of
background action - deleting existing categoryoptions, rebuilding new
categoryoptioncombo ids and mapping/updating the old to the new
categoryoptioncombo ids in the affected datavalues. Not a job for the
fainthearted. Do we have any background experience in such fiddling
with existing categoryoptions (other than manually)?
It seems that what we require here is some sort of categoryoptioncombo
merge functionality in the category service? Or is this long term
functionality we need in dhis at all? Is it better solved by an
external fixer-upper tool?
Bob
Follow ups