Re: preserve value order with referential integrity overlay?

[Zhang Weiwu <zhangweiwu@realss.com>]

å 2007-08-14äç 02:01 -0700ïHoward Chuåéï
> Zhang Weiwu wrote:
> > Hello.
> > 
> > I deployed an LDAP system and a set of applications around it that is
> > highly sensitive to the order of values, e.g first telephoneNumber must
> > be the main contact method, first value of companyRepresentative must be
> > the DN of the main contact person.
> 
> That is a complete misuse of LDAP. Attributes are *SETS* of values. "Sets" are 
> inherently unordered. The LDAP and X.500 specs and plenty of other docs tell 
> you not to rely on the order in which values are returned.

The misuse of this is first introduced by being able to have multiple
values of telephone number, where we always put the primary number the
first one and it worked several years. Later we used businessCategory
which also have strict order requirements and that worked several years.
So I begin to think I can do the same to companyRepresentative. Call me
stupid or having not learnt true spirit of LDAP, I learn by starting
with some theory and complete most of the theory with self experience,
this worked with almost all other IT systems except LDAP. I don't know
why. In LDAP world things often arranged different than my
understanding.

> 
> > What's the best way to solve this problem? I can only think of 1) try to
> > modify source code of slapo-refint to make it maintain order (big
> > problem, never worked on C source code before, 
> 
> Obviously not the way to go.
> 
> or 2) try to use several
> > attributes like "FirstCompanyRepresentative",
> > "SecondCompanyRepresentative", "ThirdCompanyRepresentative"
> 
> Clumsy, and only feasible if you have a fixed limit on the number of values you 
> want to manage.

That's my trouble, it's clear the number of representative is not
limited, many records have 6 or 8 of them!

> 
> You might consider something like
> http://www.highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html
> which is only slightly less clumsy, and that spec needs to be revised anyway.
> Whatever solution you choose is going to require your clients to be modified to 
> adapt to the solution.


Yeah very helpful source of information. I am reading it and hope to
find a solution...