dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi Ime

On 15 September 2011 06:06, Ime Asangansi <asangansi@xxxxxxxxx> wrote:

> Hi Bob,
>
> This is super neat, and its a use case that is very useful.
> I've had to generate all that extra stuff I didnt 'need'.
>
> This will also streamline metedata generation because one will only need to
> generate and pass metadata for only de/ou/period.
>
> But I wonder; what's the difference between orgunitId and orgunit in your
> example.
>


That's a typo.  Please take a look at the pdf file I sent out earlier this
week as that is more correct.


> Also, some elements don't use any categories, but the model references a
> default categorycombo. How will that look in your proposed schema?
>

The default categorycombo is just that - default.  So in the absence of any
categories the categorycombo is automatically set to default when saving
datavalues.

>
> Would you branch Jo's code in a way we could use easily test yours as a
> module? or...
>

The reading of this format is already implemented in the import/export
module.  It is tightly coupled with Jo's code in the sense of making use of
the same element/attribute name strings defined in his beans.  So you can
already use it by just importing the xml file.  To test you should ideally
set up some codes in your database.  We should try and do this in the demo
instance so people can try it there.  Meanwhile I would suggest to test:

(i) pick an orgunit and assign it a code if it does not already have one (eg
ou1)
(ii) pick a small dataset and assign it a code (eg dataset1)
(iii) assign codes to the dataelements within the dataset
(iv) assign the dataset to the orgunit

Then you should be able to import datavaluesets according to the examples
given.

Alternatively you can use the existing uuids instead of the codes.

(It might be worth having a startup routine which automatically assigns
codes based on the existing internal ids where they do not already exist.)

Regards
Bob


>
> Thanks
>
> Ime
>
>
> --- On *Thu, 9/1/11, Bob Jolliffe <bobjolliffe@xxxxxxxxx>* wrote:
>
> The implication of adding all the above will be that whereas the
> datavalueset above will remain valid (except perhaps shifting to
> storedBy), the following would also be valid:
>
> <dataValueSets orgUnitId="code" dataElementId="internal"
>   <dataValueSet  orgUnit="23" period="201004" storedBy="Bob" >
>     <dataValue dataElement="2" value="4" Sex="1" />
>     <dataValue dataElement="2" value="5" Sex="2"/>
>     <dataValue dataElement="4" value="43" Sex="1" Age="3" />
>     <dataValue dataElement="5" value="44" Sex="1" Age="3" />
>   </dataValueSet>
> </dataValueSets>
>
> I am pretty sure I can implement the above without breaking what is
> currently there.  One possible but minor breaking change I would
> suggest to improving parsing of very large datasets might be to
> abbreviate some well known element names to dv, de and v for
> compactness.
>
>