dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2009/3/20 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>
>>
>> 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.
>
> OK but what does this give us in terms of PeriodType-determining if this
> default DataSet has a null PeriodType?

Nothing really.  The only effect would be you have an index on the
unassigned DataElements for what its worth.  Mainly it would be useful
for determining easily the available DataElements which can be added
to a DataSet.  Maybe its a nonsense idea - I was just trying to think
of ways to make editing DataSets reasonably straightforward.

>
>>
>> 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.
>
> Yes. We need at least service method:
>
> Collection<DataElement> getDataElementsByPeriodType( PeriodType )
>
> and getter on the DataElement object:
>
> PeriodType getPeriodType()
>
>
> I guess we could make a branch, start coding and see how it works out.

Sure.  So long as we are adding methods we won't be breaking anything
in terms of backward compatibility.  Just enforcing application level
constraints.  Then we can really encourage (enforce?) upper layers to
strictly interact with the data via the API.  Even if this might
occasionally mean making some lightweight API methods which bypass the
ORM.

>
> Another issue would arise in the (exotic) situation where someone assigns a
> DataElement to a DataSet, enter data for it, then removes it from the
> DataElement. The data is there, but how do we deal with it in regard to the
> mentioned required functionaly (trend analysis, datamart) ?
>

Yes this gets a bit weird (I presume you mean removes it from the
DataSet).  I'm guessing you haven't lost the data because the
dataValues each have a PeriodID which in turn is linked to a
PeriodType.  I suppose that (in such an exotic headspace) DataElements
can in fact change their PeriodTypes over time, though I imagine its
not a great idea.

The effect would be the same in the explicit relationship case, if
someone assigns a DataElement to a DataSet, enter data for it, then
changes the PeriodType of the DataElement ...

Cheers
Bob