dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2009/3/20 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.

a bit slower but really not much.  And not more complex application
logic above the API:

Collection<DataElements> PeriodType::getDataElements()

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

I haven't seen the DHIS1.4 model so I can't really say.  But I think
we all agree that having DataElement::getPeriodType() is a good thing.
 And this seems to be borne out from the 1.4 experience.

>>
>> 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.)

Yes agreed.  We currently have:

<set name="dataElements" table="datasetmembers">
      <key column="datasetid"/>
      <many-to-many class="org.hisp.dhis.dataelement.DataElement"
          column="dataelementid" foreign-key="fk_dataset_dataelementid"/>
    </set>
in the DataSet.hbm.xml

We would need a mirror association in the DataElement.hbm.xml in order
to get DataSets smoothely.  But still using the same mapping table.
At worst this will involve making a new index.

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

Yes this is true.  But what do you think of the idea to enforce
DataSet membership having a default DataSet for all the delinquents?
I'm not sure if it can be enforced by the schema, but at least by the
application.

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

I don't know if its about right or wrong.  There are pros and cons of
both approaches.  What you gain on the swings you lose on the
roundabouts :-)

In the explicit case the application will have to enforce that DataSet
members all have the same periodType.

In the implicit case the application will have to enforce that
DataElements can only be members of multiple groups if these share the
same PeriodType.

The net result as far as the Data API is concerned can and must be the
same.  Perhaps we should define exactly what extra methods we want in
the API first.  We have already identified a few.  Then decide whether
a database change is necessitated by these.

Bob