dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2009/3/20 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>
>>
>> There is not much to be gained in terms of simplicity if you drive the
>> functionality down to the data model API.  The way you make the
>> relationship explicit is to provide the DataElement class with a
>> method called getPeriodType().  The detail of how it implements that
>> is invisible to the user of the method.  True the implementation of
>> getPeriodType() will be slightly less efficient, but how many times
>> will it be called in a data intensive operation anyway?  In most cases
>> you could probably call it once in the constructor and reuse the
>> result as much as you can.
>
> Yes I agree that putting this in the API makes it more usable - but
> currently there are no association from DataElement -> DataSet, only DataSet
> -> DataElement, meaning you cannot access a DataElement's DataSets directly
> without using a query. Of course we could make this association
> bi-directional but then again this involves another association, which you
> want to avoid.

Agreed.  The modal scenario is that you have a DataSet and you want to
list DataElements.  The reverse scenario, finding the DataSet (in fact
Sets) which an Element is a member of, is less common and doesn't
justify a direct lookup.

But yes, it would be very useful to have a method in the DataElement
API something like a

Collection<DataSet> DataElement::getDataSets()

>
>>
>> I'm thinking that DataElements which are not members of any DataSet
>> should probably be considered as "inactive" or not yet assigned in the
>> application (I might be wrong - see below).  Assigning a DataElement
>> to a DataSet would involve calling getPeriodType() on it.  If it
>> returns NULL then the assignment will always succeed.  If it returns a
>> PeriodType then it will succeed if the DataSet you are assigning to is
>> of the same PeriodType():
>>
>> DataSet::assignDataElement(DataElement de)
>> {
>>   PeriodType pt=de.getPeriodType();
>>   if (pt != NULL && pt!=this.getPeriodType()) {
>>       throw new PeriodTypeMisMatch()
>>   }
>>
>>   etc ...
>> }
>>
>> Of course all of this does fall apart if you are saying that it is
>> acceptable that active DataElements can indeed be legitimately not
>> part of any DataSet.
>
> A DataElement can exist perfectly without a DataSet. On the other hand
> without a DataSet there wouldn't be any data registered for it, and things
> like gap analysis, regression analysis become irrelevant. It would be a
> "soft" data integrity problem, but not a "database error".
>

So that is ok.  It can exist but doesn't really become relevant unless
its part of at least one set.  So I guess it doesn't need to have a
PeriodType associated with it while it is in this state.

>>
>> My fear of introducing redundancy in the datamodel is driven more by
>> the fear of introducing accidental complexity.
>
> I still believe deriving PeriodType from DataSet would be more complex;
> think of a scenario where you eg. want to edit a monthy DataSet and list all
> available "monthly" DataElements. How do you query this?

You would simply return all DataElements which are members of
"monthly" DataSets (easy) plus the unassigned ones (less easy).

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.

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.

Cheers
Bob


>
>
>