dhis2-devs team mailing list archive

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



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



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