dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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

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.

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