dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 24 May 2012 09:13, Morten Olav Hansen <mortenoh@xxxxxxxxx> wrote:
>>> Lars, are we using this for anything? (is this part of the grid
>>> renderer etc?) I remember making it.. but never used it..
>>
>> That is a good question.  Please shout up if this is currently in use.
>>  Either way I can leave the single method there if people have already
>> built stuff with it.  If not, then I might take liberty to modify it
>
> I don't think we modify it.. but Lars would know. I was thinking about
> our grid rendering, but that is done by the ReportTableController I
> think.
>
>> Strange though it might seem coming from me, I've not been tempted to
>> do either an xml or json rendition.  For this sort of data, compressed
>> csv seems most appropriate.  Starting to think like one of those
>> R-struck statisticians :-)
>
> :-)
>
> I think at least JSON would be nice (so you can create a web based
> data browser, etc).

Not sure if web based aggregate data browser is high on the list of
priorities.  I guess if people want to browse data they would
typically do this through a reporttable.  Thats what I do anyway.  My
priority is to simply have a convenient place to get hold of the
gzipped csv streams for mydatamart using basic authentication.

The current AggregatedValueController is neat, but there are two
things which need to be different:
1.  it doesn't make sense to pass the list of orgunits where that list
can be very large.  With the mydatamart request we post two parameters
- the "root" orgunit and the "level" and let dhis figure out which
orgunits are at that level in this part of the tree.  That was the
requirement to be met.   Though having said that, having the ability
to pass a list might also be useful - for example if the list of
orgunits you are concerned with spans different parts of the tree.
This can be the case with NGOs etc.  But even there it might make
better sense to use a parameter (like orgunitgroup) to filter rather
sending an explicit list.
2.  the jackson object based approach is nice, but won't scale well to
many concurrent requests for very large chunks of data, which is what
we are seeing in practice.  Which is why I am streaming off a jdbc
iterator which uses a finite and controllable amount of memory.

So maybe I should leave what is there alone and simply move the
current actions across from reporting/exp to web-api and map it to a
different url than aggregateValue.  Though this might be confusing.
Again, is anybody using aggregateValue in the web-api?

Regards
Bob


>
> --
> Morten
>
>>>
>>> --
>>> Morten
>>>
>>>> Bob
>>>>
>>>>>
>>>>> --
>>>>> Morten
>>>>>
>>>>>> Cheers
>>>>>> Bob