dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

Data elements derive their period type from the data sets they are members
of.

On Thu, May 20, 2010 at 11:44 AM, Ola Hodne Titlestad <olatitle@xxxxxxxxx>wrote:

> Hi,
>
> After Kim Anh's email about the use of the same data elements with
> different period types I dug up this old discussion from March 2009.
>
> What is the status on this work, or did we not conclude this?
>
> Ola
> ----------
>
> 2009/3/20 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
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>