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