dhis2-devs team mailing list archive

[Jo Størset <storset@xxxxxxxxx>]

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