dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 15 February 2011 15:16, Lars Helge Øverland <larshelge@xxxxxxxxx> wrote:
>
>
> On Tue, Feb 15, 2011 at 4:13 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>>
>> On 15 February 2011 14:37, Lars Helge Øverland <larshelge@xxxxxxxxx>
>> wrote:
>> >
>> >
>> > On Tue, Feb 15, 2011 at 3:26 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>> > wrote:
>> >>
>> >> On 15 February 2011 14:09, Lars Helge Øverland <larshelge@xxxxxxxxx>
>> >> wrote:
>> >> >
>> >> >
>> >> > On Tue, Feb 15, 2011 at 2:34 PM, Jo Størset <storset@xxxxxxxxx>
>> >> > wrote:
>> >> >>
>> >> >> Den 15. feb. 2011 kl. 18.40 skrev Bob Jolliffe:
>> >> >>
>> >> >> > Simple validation seems to work ok.  I get an "Aw, Snap! ..." when
>> >> >> > posting twice with the same period but that is probably something
>> >> >> > you
>> >> >> > are not catching yet.
>> >> >>
>> >> >> Should work now.
>> >> >>
>> >> >> > I don't agree with this.
>> >> >>
>> >> >> I know :) I don't necessarily agree myself, but it is also a matter
>> >> >> of
>> >> >> what is practically possible.. (And it might make sense to have a
>> >> >> simpler
>> >> >> json-oriented web api vs. a more fullfledged xml format for heavy
>> >> >> imp/exp.
>> >> >> Are you coming to Oslo in March by any chance, then we can fight it
>> >> >> out! )
>> >> >>
>> >> >
>> >> > Can you please explain why it is not practically possible to have dxf
>> >> > as
>> >> > the
>> >> > root element?
>> >> > I don't have anything against grouping datavalues in sets to make the
>> >> > format
>> >> > more compact. But, first, we currently don't have any real
>> >> > requirements
>> >> > or
>> >> > use-case where we want to persist the "datavalueset". Second we
>> >> > currently
>> >> > have no support for it in the model. So whats the point of modeling
>> >> > our
>> >> > exchange format this way?
>> >>
>> >> Well partly because this structure models the way data is produced.
>> >> In sets.  Off a form or off an import.  SDMX data for example also
>> >> arrives in sets.  While there is no support in the model it simply
>> >> means that we can lose information regarding the set.  It becomes
>> >> important where you might want to rollback a set or identify where
>> >> some particular has come from.  Currently this is sort of implicitly
>> >> keyed but there are benefits in making it explicit.  For example you
>> >> can't currently trace a datavalue back to whether it was entered
>> >> through a dhis form, whether it arrived from one of Jo's 5000 phone's
>> >> or whether it was imported from iHRIS (or whatever).  You can populate
>> >> the comment of all the datavalues but that's really expensive.
>> >
>> > Yes thats fine, but my point is that we don't support it in the model...
>> > So
>> > I still don't understand why we should require senders to provide this
>> > info
>> > as it currently simply will be ignored.
>>
>> Well for a set of 100 datavalues you must either require them to
>> provide the attributes in Jo's datavalueset once or a 100 times :-)
>> So it makes sense to use it.  Even if we don't model and store the
>> datavalueset object itself.
>
> Yes agree with that and I don't have anything against grouping values for
> the benefit of making it compact. I am more concerned about having two
> different formats and parsers.

Agree.

>We can discuss later.
>
>>
>> >
>> >>
>> >> There are also savings to be had on storage by inheriting atttributes
>> >> like period and orrgunit from a dataset rather replicating in each
>> >> datavalue.
>> >
>> > That would require that we normalize and decompose into datavalueset
>> > (dataset,period,orgunit) and datavalue(dataelement, categorycomboid).
>> > And
>> > that would effectively change the whole system and not happen anytime
>> > soon...
>>
>> Agree.  Mind you I suspect this would might prove to be a smaller
>> change to the whole system than the concept business which will be
>> more disruptive.  The benefit of the encapsulation which we have in
>> the datavalue api is that  period, source, storedBy etc are all
>> private so how the likes of getPeriod() works is easily reimplemented
>> and so much of the change would be transparent.
>>
>> Anyway ... back to work :-)
>>
>> Cheers
>> Bob
>>
>> >
>> >>
>> >> It's not a model change I would propose immediately (I think we have
>> >> enough zooks to sort out) but surely it is hard to argue that its not
>> >> the (proverbial) right thing to do.  Meanwhile the way Jo has it in
>> >> his xml looks fine to me.
>> >>
>> >> Cheers
>> >> Bob
>> >>
>> >> > Yes we might need it sometime in the future but
>> >> > then we should implement it when we need it.
>> >> > I also find it weird that we really need to implement two parsers for
>> >> > this.
>> >> > More work and more code to maintain.
>> >> > The uuids will go for a new Identifier property for version 2.2 and
>> >> > make
>> >> > things less verbose btw.
>> >> > Lars
>> >> >
>> >> >>
>> >> >> > Your use of DataValueSet here is very welcome - as you know I have
>> >> >> > been advocating this for a while.  Would be nice also to persist
>> >> >> > it
>> >> >> > to
>> >> >> > provide audit (and simplify dtavalue store) but that is maybe too
>> >> >> > much
>> >> >> > for now.
>> >> >>
>> >> >> Yes, that would have to be the next topic. Let's see if anyone else
>> >> >> take
>> >> >> the bait :)
>> >> >>
>> >> >> Jo
>> >> >> _______________________________________________
>> >> >> Mailing list: https://launchpad.net/~dhis2-devs
>> >> >> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> >> >> Unsubscribe : https://launchpad.net/~dhis2-devs
>> >> >> More help   : https://help.launchpad.net/ListHelp
>> >> >
>> >> >
>> >
>> >
>
>