dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

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. 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
> >> >
> >> >
> >
> >
>