dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

On 16 Feb 2011 16:32, "Bob Jolliffe" <bobjolliffe@xxxxxxxxx> wrote:
>
> On 16 February 2011 21:23, Lars Helge Øverland <larshelge@xxxxxxxxx>
wrote:
> > Ok maybe i was unreasonably blaming you for this, sorry about that.
> > Including dataset in the exchange format for completeness and locking
> > purposes is fine and makes sense. Its the idea of directly linking
datavalue
> > to dataset on the persistence side for tracking purposes i am against.
Lars
>
> And you are right to be against that.  But if not the dataset then we
> are short of something else ... :-)  Whether it's important or not is
> another question.
>

Yes we might be short of something else. I am just explaining that the way
dataset is today it is unsuitable for tracking purposes. And as Ola says
there are good reasons for having dataset the way it is.

And whether its important depends on whether users requires it. When they do
we will have to invent something.

> >
> > On 16 Feb 2011 13:48, "Jo Størset" <storset@xxxxxxxxx> wrote:
> >>
> >> Den 16. feb. 2011 kl. 22.07 skrev Lars Helge Øverland:
> >>
> >>> Ola's point here is important
> >>
> >> Agree.
> >>
> >>> and that's why it is wrong and ambiguous to include the dataset on the
> >>> datavalueset like Jo has implemented it:
> >>
> >> I anything is "wrong and ambiguous" it is inherited from the design
> >> already there, it's not something I'm implementing. And it is certainly
not
> >> something that comes from including a dataset identifier on *POSTED*
> >> datavaluesets.
> >>
> >>> A data element can appear in multiple datasets. So there is no
guarantee
> >>> that a data value is coming from data set a since it was received from
a
> >>> datavalueset b. A datavalue might very well be subsequently updated
from any
> >>> number of other data set/datavalueset. So a datavalue can be added
from a
> >>> dataset a, updated from a dataset b, updated again from a dataset c...
Where
> >>> would you say it comes from?
> >>
> >> I would say when the user has just edited and posted the form for
dataset
> >> A it comes from dataset A. Do you seriously mean to say that that is
> >> ambiguous while *guessing* is unambigous? DataSet A might be locked
while
> >> dataSet B is not. You are saying that guessing what datavalueset to
check
> >> for locking on is *the right way*, while knowing is wrong? I mean,
> >> seriously... It's not that there aren't plenty of real concerns here,
this
> >> is just sour grapes.
> >>
> >>> And if we had a one-to-one relationship between data element and
dataset
> >>> it would be unnecessary to add the dataset to the datavalueset since
it
> >>> could be derived from data element. I was trying to explain this
before this
> >>> was commited but it was ignored.
> >>
> >> And of course everyone obviously agrees.. if you have a one-to-one
> >> relation you can the deduce one from the other. But we don't, and if we
had
> >> we wouldn't have this discussion, so then the point is rather mute,
wouldn't
> >> you say?
> >>
> >>> That said I don't have anything against groping datavalues in the
> >>> exchange format to save space, which is a different question.
> >>
> >>> The dataset thing works quite well and lets not complicate this more
than
> >>> necessary. If users one day require improved tracking of datavalues
lets
> >>> deal with it then.
> >>
> >> k
> >>
> >> Jo
> >