dhis2-devs team mailing list archive

[Jo Størset <storset@xxxxxxxxx>]

Den 1. sep. 2011 kl. 17.04 skrev Bob Jolliffe:

>>> 1.  We should shift storedBy up to the dataValueSet level.
> 
> My thinking would be that what is relevant is who has
> stored this value in *this* database.  Usernames from strange
> databases wouldn't make much sense anyway. 

> Its not critical either way at the moment - just looks a bit untidy.
> Thus far, unless I hear compelling argument to the contrary, it seems
> better to move it up.  Will wait and listen.

We haven't really talked about who is "doing the storing" in cases like this, but I would think a system user scenario, where a system user ("systemX") would be the most correct?

In the current handling, this attribute is an optional value, if it's empty currentUserService.getCurrentUsername() will be used. So I think maybe just removing this option for the time being (until it is actually needed) is just as well. Unless we have a use case where we explicitly need to allow the external system to set it, in which case we could let that use case decide.

>>> 2.  I don't think categoryOptionCombo should *necessarily* be exposed
>>> to the external world.

Trusting you to have to oversight over the mapping to the internal model, I think this makes sense, it should make the meta model easier to articulate in a rest api, as well. 

>>> 3.  On the question of identifiers ....

> I agree that uuid is not the most gentle default.  I just suggested it
> because you were already using it.

I just used uuids because you were already using it :) I guess choosing the default is not an immediate problem, anyway.. 

>>> I can live with long names or short.

Me too (with an ever so slight preference for understandability vs. "premature" optimization)

I certainly support the changes. With a couple of cases of external mobile solutions needing an api for this, it is a good time to stabilize this and get it clearly documented. What is your use case, btw? Thought you were all sdmx :)

Jo