dhis2-devs-core team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

I have just noticed that Morten has already implemented an
ImportSummaries class.  Perfect.  I can use that as a returned object.
Morten, what are you using this class for currently?  Do we have other
instances where we are importing multiple datavaluesets?

On 12 June 2015 at 13:40, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
> Hi
>
> As yoou have seen I have already started to commit a few bits of code
> in support of the ADX implementation.  I hadn't been planning to do
> this so will proceed quite slowly, but let me outline the approach I
> am considering for your comment and suggestion.
>
> 1.  Currently we have a datavaueset service which can import dxf2 data
> from an inputstream.
>
> 2.  I would like to use that existing service and place the adx
> service as a thin veneer above it rather than create a lot of
> duplicated code.
>
> 3.  The adx data importer would read its adx input from a stream and
> convert that into a dxf2 stream.  The main tasks it would need to
> perform are:
> (i)  convert periods into dxf2 format
> (ii) lookup catoptcombos and attributeoptioncombos for the dimensions
> in the adx message
> All other attributes and ImportOptions would be passed through
> directly to the dxf2 datavalueset service.
>
> 4.  In order to present the resulting dxf2 to the service as an
> InputStream it would have to use PipeReader/PipeWriter combination
> (Something Lars will recall from earlier dxf1 code).  The equivalent
> alternative would be to post the dxf2 datasets backout to the REST
> endpoint but that seems wasteful and more awkward.
>
> Does that approach sound reasonable?
>
> I have some lingering uncertainty about the best way to deal with
> ImportSummary.  The adx data is naturally grouped by orgunit/period.
> So I would likely split the stream and post each as a separate dxf2
> datavalueset.  So probably this would imply collecting the results
> into an <ImportSummaries ... /> element.  ADX is currently silent on
> the result message as it deliberately does not define the transaction
> (just the message) so we have some latitude here to do whatever is
> best.  The above is my best suggestion.
>
> Cheers
> Bob