dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

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 <larshelge@xxxxxxxxx>:
>
> 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
>
>