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 <[email protected]>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 <[email protected]> > >> 2009/3/20 Lars Helge Øverland <[email protected]>: >> > >> >> >> >> 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 : [email protected] >> Unsubscribe : >> https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs> >> More help : https://help.launchpad.net/ListHelp >> > >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
