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 <bobjolli...@gmail.com> > 2009/3/20 Lars Helge Øverland <larshe...@gmail.com>: > > > >> > >> 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@lists.launchpad.net > 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 : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
