I know we have had this discussion of uniqueness of orgunit names on
and off over the past few years. But we have moved quite a distance
since then with our increasing use of uids and codes to uniquely
identify objects. So my question: have we reached a stage now that
we can finally drop the uniqueness requirement on orgunit names? Is
there anywhere remaining which absolutely depends on this requirement?
Other than dxfv1 import which will match on code by preference
anyway.
If there is no other truly compelling reason to maintain this I'd like
to propose that we consider dropping this constraint now. Can we
think of a list of what breaks if we do? And if we can workaround
those breaks.
This will be particularly important when we consider consuming orgunit
names from external services such as a facility registry. In fact
that has always been a bit of a problem (we always get the names from
somewhere) but we have tended to do this orgunit import as a one-off
task and had the luxury to massage uniqueness into the names in the
process. If we are considering ongoing synchronisation with external
sources I think it will be hard to impose our name-uniqueness
requirement on those various sources.
I know we have had this discussion of uniqueness of orgunit names on
and off over the past few years. But we have moved quite a distance
since then with our increasing use of uids and codes to uniquely
identify objects. So my question: have we reached a stage now that
we can finally drop the uniqueness requirement on orgunit names? Is
there anywhere remaining which absolutely depends on this requirement?
Other than dxfv1 import which will match on code by preference
anyway.
If there is no other truly compelling reason to maintain this I'd like
to propose that we consider dropping this constraint now. Can we
think of a list of what breaks if we do? And if we can workaround
those breaks.
Or Jason's compromise suggestion to change the uniqueness constraint
to (parentid,name) sounds good to me.
···
On 4 April 2012 08:37, Bob Jolliffe <bobjolliffe@gmail.com> wrote:
This will be particularly important when we consider consuming orgunit
names from external services such as a facility registry. In fact
that has always been a bit of a problem (we always get the names from
somewhere) but we have tended to do this orgunit import as a one-off
task and had the luxury to massage uniqueness into the names in the
process. If we are considering ongoing synchronisation with external
sources I think it will be hard to impose our name-uniqueness
requirement on those various sources.
the only reason I can think of is that dxf1 import will not work
anymore.. Since we are effectively matching on names during datavalue
import. Hopefully we can remove this soon as we are phasing in dxf2.