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 <[email protected]>: > > 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 >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~dhis2-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
