dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi Jason

I don't think we're voting yet :-)  For the moment we have uuids and we also
have a uniqueness constraint on names.  Changing that in a hurry would have
a lot of rippled consequences - even some good ones, I here you - which are
nobody's priority to address at the moment.  But I'd just like to get an
idea of what we would ideally want first.  And keep hammering my hobby horse
that names and identifiers are different concepts for good reason.

Generally the choice of globally unique identifiers come down to a choice of
either a form of uuid or a form of uri (which can be either a url or a urn -
there are religious wars on that).  There are many pros and cons of the
three approaches.  In general they all suffer from the performance impact of
long strings.  Which is why I favour the use of a short string or code
internally, which can be concatenated to a longer namespaced uri when we
have to interoperate between systems.  But that solution is not perfect
either.

Cheers
Bob

PS.  I would have though of Georgia as more of a KFC county than a McDonalds
one.  Similar problem mind you :-)

2009/9/28 Jason Pickering <jason.p.pickering@xxxxxxxxx>

> If we are voting here, I would say that any naming convention should
> be avoided at all costs, as they tend to be rather arbitrary, and
> easily manipulated.
>
> I am also much against the unique name restriction currently imposed
> in the data model. We have situations where there identially named
> facilities within the same organizational unit (think of McDonalds
> here). I think DHIS is even more restrictive that this example. I grew
> up in Pickens County, Georgia. There is no reason why there cannot be,
> or should not be identically named organization units. DHIS 1.4 gets
> around this by the use of naming conventions, which causes me no end
> of headaches when I have to produce a report. I suppose the same could
> apply to other concepts, such as "Age".  They should be able to be
> distinguished through other means.
>
>  I am not sure if a UUID is the best way for this, as it does have
> potential performance implications, but it is certainly preferably to
> any naming convention that may be enforced through the UI and not the
> DB.
>
> Regards,
> Jason
>
>
>
> On Mon, Sep 28, 2009 at 3:53 PM, Jo Størset <storset@xxxxxxxxx> wrote:
> > Basically I agree with you, just one minor opinion :)
> >
> > Den 28. sep. 2009 kl. 14.36 skrev Bob Jolliffe:
> >
> >> What seems to then happen is that implementors tie themselves up in
> knots
> >> trying to find new and imaginative ways of naming the "Age" categories
> so
> >> that they are unique from one another when there is really no compelling
> >> reason to this.  With a structure like:
> >>
> >> <category id="23" name="Age" uid="4454545656456477756" />
> >>
> >> where id is just the internal key and uid is a unique identifier (which
> >> could be a uuid but not necessarily) then there is really no reason not
> to
> >> have any number of categories with the name "Age" where each one has
> >> different sets of category options.
> >
> > The problem with non-unique names is that you can easily get into
> unintended
> > situations where the name is displayed in a context where the difference
> > between "versions" is important for the person using the system. I don´t
> > really know dhis well enough, but I have seen this kind of problem other
> > places.
> >
> > Jo
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> > Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
> > More help   : https://help.launchpad.net/ListHelp
> >
>