dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

>
>
> You are right that not having a reverse association makes selecting
> all the "unassigned" DataElements a bit tricky.  Perhaps the most
> robust solution is to have a default unassigned DataSet - with a NULL
> periodType.  All new DataElements start life in this DataSet.  This
> makes finding the available dataElements pretty trivial and we can
> also rigorously enforce that a dataElement MUST be a member of a
> dataSet which is a good thing.


This will be a complexity trade off between data model / database schema and
application logic. Getting DataElements for a PeriodType will definitely
involve a more complex and slower query or additional application logic.

As for accidental complexity / future implications the DataElement ->
PeriodType association has been in use in DHIS 1.4 for several years and
proved to be working. What do we know about this approach?


>
>
> You might be right on the performance of dataMart etc.  It will really
> come down to how often you have to call getPeriodType() which
> shouldn't be too much - the real data crunching meat is in the
> datavalues not the dataelements I think.  If indeed it proves very
> costly then it might justify the hacking the schema, but I think we
> should try implementing at the API level first.  Reimplementing
> DataElement::getPeriodType() can be done if necessary.
>


I guess Hibernate will cache the DataSet lookup anyway. But remember we
cannot implement getPeriodType in the DataElement object if there is no
association DataElement -> DataSet.


> On second pass this is actually quite trivial to implement because we
> have the go-between DataSetMembers(?).  Finding the DataSets
> associated with a DataElement should be as straightforward as finding
> the DataElements associated with a DataSet.

Yes, but "datasetmembers" is a mapping table in the database, we still need
an association in the object model.

The "implicit" approach can be done, but it involves a DataElement ->
DataSet association, and more complex queries/programming model. (If the
DataElement -> DataSet association is omitted; a call to the service layer
to get the PeriodType for a DataElement.)

The "explicit" approcah also involves an association (DataElement ->
PeriodType). I am not sure if one could say it involves redundancy, as we
don't have a model enforcement of one-or-more DataSet memberships for a
DataElement.

I opt for the latter approach. Of course I might be wrong:)