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
_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
