dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Re-looking at that old discussion reminds me:

The period type of a datavalue can always be deduced from the period.
So it is actually possible to import datavalues for dataelements which
are not members of a data set and not lose the period type
information.

periodType = dv.getPeriod().getPeriodType();


2010/5/20 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
>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> More help   : https://help.launchpad.net/ListHelp
>>
>
>