← Back to team overview

dhis2-devs team mailing list archive

Re: [Dhis-dev] DataElement -> PeriodType association

 

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
>

Follow ups

References