Since I started all of this, I feel compelled to write one last mail here. I think Lars suggestions are the way to go. They are practical, ensure compatibility with existing systems, and are certainly achievable pretty quickly. Having the data element group sets functionality would be a major step forward to producing useful, flexible outputs for end-users.
I think some of the limitations, quirks, and advantages of the current model have been highlighted. I suspect we need to look deeper at the details during the documentation process. I will start writing up something in DocBook format this week, commit it to the documentation branch, but would require the input of at least Johan ,Ola, Bob and others to make the document complete. Once the data element groups sets have been implemented, we can fill in the rest. As I have made clear, we are dealing with a hybrid system here in Zambia, with 1.4 and 2 running side-by-side. I can write up this use case, but cannot add anything about the "pure" DHIS2 system, where the lack of the data element group sets may not be such an issue. Thanks Lars for prioritizing this. It will be a big step forward here once implemented. Regards, Jason 2009/10/5 Lars Helge Øverland <[email protected]>: > > Big thanks to all for illuminating the pros and cons of the current > multidimensional model. It was designed in 2006 basically to support the ICD > based dataentry, and we must admit that Bob is at least partially right when > saying that output could have been given better thought. Anyway it is not > working out too bad either it seems. > > I like Bob's suggestion for simplifying the model and it would apparently > made querying easier and improve the user interface. I have a few concerns: > > - Feasibility. The Category-related model is integrated into 9 out of 11 > service projects in DHIS 2. Re-factoring and testing all this would take > months. > - Backwards compatibility. Lots of databases and data-entry forms exist in > the field. Conversion must be managed. > - Suitability for the data-entry module. It seems likely that the > CategoryCombo class can be "emulated" through the API. > - Does it cut tables to change from m-n to 1-n? Using join tables to > represent 1-n associations is preferred by many as it keeps the domain model > cleaner. > > If people say we can live with the current model I'd say we do just that. > Anyway Bob's suggestion should be documented and looked at again later. I > think the point about "input without output is statistical m..." is valid. > At least we will need to focus more on how to make "the goodness float up". > > > Re the data element / indicator group set I think this is something we can > do without risk. It won't change the existing model and won't break anything > and wouldn't take too long to implement. Will start on it on Wednesday. A > minor comment here is that I believe we should keep the exclusiveness and > compulsory-ness of the group set optional (..eh) like we have it for > organisation unit group sets today. > > > Finally I hope people who are troubled about the lack of documentation would > use Jason's instructions and convert some of this newly discovered wisdom > into... documentation. > > > cheers > > Lars > > _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
