Re: preserve value order with referential integrity overlay?
Peter Marschall wrote: Maybe as another alternative attribute options might work (with some help from clients): telephoneNumber;x-sort-1: telephoneNumber;x-sort-2: Then the client needs to sort the values according to the value after x-sort-. I have always wondered why this approach was not considered for the OpenLDAP configuration. Good question. IMHO this would have also avoided some inconsistency regarding matching rules. Ciao, Michael.
Re: preserve value order with referential integrity overlay?
Hi, On Tuesday, 14. August 2007 11:01, Howard Chu wrote: 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. 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. 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. Maybe as another alternative attribute options might work (with some help from clients): telephoneNumber;x-sort-1: telephoneNumber;x-sort-2: Then the client needs to sort the values according to the value after x-sort-. I have always wondered why this approach was not considered for the OpenLDAP configuration. Regards Peter -- Peter Marschall [EMAIL PROTECTED]
Re: preserve value order with referential integrity overlay?
Thanks for this short but clear information which is as long as needed!
The difference here between relational database and LDAP is we cannot
design LDAP so we begin to expect more from LDAP, e.g. in case of
favorite drink order, a table can be designed more complex to preserve
order, but LDAP structure cannot be designed. However I think this is
again my mistake, because LDAP structure CAN be designed by changing
value format. I can design the client must not directly store the name
of drinks, it should store the drinks in a format a number followed by
the drink. e.g.
favoriteDrink: 1 coke
favoriteDrink: 2 beer
So here I used to think usuall values in db can be presented to user
as-is, with this new format, the client remove the leading digit after
sorted values and present the result to users. The change of table
structure in RDBMS map to the change of value format in LDAP, this is
the part that people don't get fast and easily.
But having gone this far, my solution is already very close to that of
Chu, so I get the idea of Chu's design now. I am very happy and thankful
that openldap already implemented Chu's solution so that I have less to
do on the client (the client code for sorting and re-calculating index
numbers of values are no longer needed). What easily frastrates
administrator and developers is if some problems don't have a solution
at all, e.g. in my case companyRepresentative order is vital and total
number is unknown, the db by itself provided no solution and you cannot
re-design the database! I am glad I am wrong, there is a solution.
Change value format needs to update client, but it's better than I can
do nothing about it.
And thanks for your time!
在 2007-08-14二的 22:28 +0200，Pierangelo Masarati写道：
I don't want to make this longer than necessary, but if you have a table
favourite_drink
person_id, drink
containing
'ando' 'coke'
'ando' 'beer'
and you
delete from favourite_drink where person_id='ando' and drink='coke';
and
insert into favourite_drink (person_id,drink) values ('ando','wine');
I'm pretty confident 'wine' will not come before 'beer', even if 'wine' is
what I really prefer.
In this sense, I think LDAP was designed to be almost as dumb as most
applications (and application developers) but not dumber. So, values with
the very same importance go into sets, and values with special importance
go into specific attributes, possibly with SINGLE-VALUE constraint if
appropriate, as I explained in my previous message.
As a general rule, don't ask software to do what can be better done by
yourself, and viceversa :)
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: [EMAIL PROTECTED]
---
--
锐业软服（国内业务） http://www.realss.cn
Real SoftService http://www.realss.com
销售咨询(Sales Department):0086 592 20 99987 (Chinese, German,
English)
国际业务(International Sales): 0086 10 8460 6011 (German and English)
联系：厦门大学科技园，嘉庚二号楼6楼
邮政：厦门大学2312号信箱（邮编361005）
Re: preserve value order with referential integrity overlay?
在 2007-08-14二的 10:30 -0700，Howard Chu写道： Zhang Weiwu wrote: One dump question, the draft you composed expires at end of 2006, does that mean this draft will no longer become RFC and (thus?) have no implementation yet? The draft is intended to document what we've already implemented in OpenLDAP. The OpenLDAP implementation will continue to exist regardless of the document status. Thanks for openldap team to having implemented this and for your draft to presented a solution. I think i will use this feature. Updating clients may be a bit difficult but had I used RDBMS updating table structure is also troublesome (although probably in that case the table can be pre-designed to be more flexible). Especially there are only a few attributes, not all attributes, in real business use have very important requirement on their order.
Re: preserve value order with referential integrity overlay?
Thanks. I already read a bit about valsort before I posed the original message, I think you mean to re-format the values like this: nationality: 1 DE nationality: 2 CN I think it really should work for me except I am going to need ordered values in DN syntax companyRepresentative: 1 cn=John,... companyRepresentative: 2 cn=Paul,... I am not sure if I can re-format string representation of DN (likely not) so I'd try Chu's solution first to see if it works. 在 2007-08-14二的 08:53 -0700，Quanah Gibson-Mount写道： --On Tuesday, August 14, 2007 5:23 PM +0800 Zhang Weiwu [EMAIL PROTECTED] wrote: Yeah very helpful source of information. I am reading it and hope to find a solution... The valsort overlay in OpenLDAP, of course. Although you'll need to define a custom attribute to hold the values for it, and you can't index them for searching, currently (or at least not for eq type searches in a meaningful way). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration -- 锐业软服（国内业务） http://www.realss.cn Real SoftService http://www.realss.com 销售咨询(Sales Department):0086 592 20 99987 (Chinese, German, English) 国际业务(International Sales): 0086 10 8460 6011 (German and English) 联系：厦门大学科技园，嘉庚二号楼6楼 邮政：厦门大学2312号信箱（邮编361005）
Re: preserve value order with referential integrity overlay?
在 2007-08-14二的 10:30 -0700，Howard Chu写道：
Zhang Weiwu wrote:
One dump question, the draft you composed expires at end of 2006, does
that mean this draft will no longer become RFC and (thus?) have no
implementation yet?
The draft is intended to document what we've already implemented in OpenLDAP.
Thanks for the info. Sorry for having to ask so many questions before I
can start using this feature: since which version this feature is
enabled? The testbed I am using runs openldap 2.3.37. I got some error
using this feature:
[EMAIL PROTECTED] ~ $ ldapadd -x -D uid=... -W
Enter LDAP Password:
dn: uid=BESG,ou=contacts,ou=china,dc=ahk,dc=de
objectClass: olcCompany
o: BASG
companyRepresentative: {0}cn=Xiaowen Zheng,uid=BESG,ou=...
companyRepresentative: {1}cn=Joerg Wuttker,uid=BESG,ou=...
adding new entry uid=BASG,ou=contacts,ou=china,dc=ahk,dc=de
ldap_add: Invalid syntax (21)
additional info: contactPerson: value #0 invalid per syntax
The sensitive data is replaced with '...' before posting.
Schema is defined as below, following examples in draft-chu-ldap-xordered-00.txt
attributetype ( ... NAME 'companyRepresentative'
DESC 'DN of the company representative'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
X-ORDERED 'VALUES'
)
Re: preserve value order with referential integrity overlay?
On 2007-08-14 09:01, Howard Chu wrote: 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. Client-side ordering seems to me a suitable use of attribute option-based subtypes, e.g.: telephonenumber;x-preference-1: (888) 555-1212 telephonenumber;x-preference-10: (202) 555-1212 IIRC, the last time I tried defining private attribute options in openldap I was disappointed in its support for extension of the option namespace, but that was a long time ago. Top-posted responses will be ignored. -- Jefferson Ogata : Internetworker, Antibozo [EMAIL PROTECTED] http://www.antibozo.net/ogata/
Re: preserve value order with referential integrity overlay?
Zhang Weiwu wrote:
在 2007-08-14二的 10:30 -0700，Howard Chu写道：
Zhang Weiwu wrote:
One dump question, the draft you composed expires at end of 2006, does
that mean this draft will no longer become RFC and (thus?) have no
implementation yet?
The draft is intended to document what we've already implemented in OpenLDAP.
Thanks for the info. Sorry for having to ask so many questions before I
can start using this feature: since which version this feature is
enabled? The testbed I am using runs openldap 2.3.37. I got some error
using this feature:
This has been present since 2.3.1, i.e., all 2.3 releases.
[EMAIL PROTECTED] ~ $ ldapadd -x -D uid=... -W
Enter LDAP Password:
dn: uid=BESG,ou=contacts,ou=china,dc=ahk,dc=de
objectClass: olcCompany
o: BASG
companyRepresentative: {0}cn=Xiaowen Zheng,uid=BESG,ou=...
companyRepresentative: {1}cn=Joerg Wuttker,uid=BESG,ou=...
adding new entry uid=BASG,ou=contacts,ou=china,dc=ahk,dc=de
ldap_add: Invalid syntax (21)
additional info: contactPerson: value #0 invalid per syntax
What makes you think that an error in contactPerson has anything to do with
the companyRepresentative attribute?
The sensitive data is replaced with '...' before posting.
Schema is defined as below, following examples in draft-chu-ldap-xordered-00.txt
attributetype ( ... NAME 'companyRepresentative'
DESC 'DN of the company representative'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
X-ORDERED 'VALUES'
)
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: preserve value order with referential integrity overlay?
在 2007-08-15三的 01:58 -0700，Howard Chu写道：
Zhang Weiwu wrote:
在 2007-08-14二的 10:30 -0700，Howard Chu写道：
Zhang Weiwu wrote:
One dump question, the draft you composed expires at end of 2006, does
that mean this draft will no longer become RFC and (thus?) have no
implementation yet?
The draft is intended to document what we've already implemented in
OpenLDAP.
Thanks for the info. Sorry for having to ask so many questions before I
can start using this feature: since which version this feature is
enabled? The testbed I am using runs openldap 2.3.37. I got some error
using this feature:
This has been present since 2.3.1, i.e., all 2.3 releases.
[EMAIL PROTECTED] ~ $ ldapadd -x -D uid=... -W
Enter LDAP Password:
dn: uid=BESG,ou=contacts,ou=china,dc=ahk,dc=de
objectClass: olcCompany
o: BASG
companyRepresentative: {0}cn=Xiaowen Zheng,uid=BESG,ou=...
companyRepresentative: {1}cn=Joerg Wuttker,uid=BESG,ou=...
adding new entry uid=BASG,ou=contacts,ou=china,dc=ahk,dc=de
ldap_add: Invalid syntax (21)
additional info: contactPerson: value #0 invalid per syntax
What makes you think that an error in contactPerson has anything to do with
the companyRepresentative attribute?
Sorry this is purely my mistake, the actual commandline script is:
[EMAIL PROTECTED] ~ $ ldapadd -xH ldap://emerson -D uid=... -w ...
dn: uid=BESG,ou=contacts,ou=china,dc=ahk,dc=de
objectClass: olcCompany
o: BASG
companyRepresentative: {0}cn=Xiaowen Zheng,uid=BESG,ou=...
companyRepresentative: {1}cn=Joerg Wuttker,uid=BESG,ou=...
adding new entry uid=BASG,ou=contacts,ou=china,dc=ahk,dc=de
ldap_add: Invalid syntax (21)
additional info: companyRepresentative: value #0 invalid per syntax
After I failed with companyRepresentative I try define a new
attributetype in similiar way and give it a name contactPerson, and
failed again. When I write the email I mixed commandline output of the
two test cases by mistake. (first time tested companyRepresentative,
second time tested contactPerson)
I am not sure if I need to post my slapd.conf, do I have to make special
setting in that file to enable X-ORDERED extension?
Thanks!
Re: preserve value order with referential integrity overlay?
--On Wednesday, August 15, 2007 9:07 AM +0800 Zhang Weiwu [EMAIL PROTECTED] wrote: Thanks. I already read a bit about valsort before I posed the original message, I think you mean to re-format the values like this: nationality: 1 DE nationality: 2 CN I think it really should work for me except I am going to need ordered values in DN syntax companyRepresentative: 1 cn=John,... companyRepresentative: 2 cn=Paul,... I am not sure if I can re-format string representation of DN (likely not) so I'd try Chu's solution first to see if it works. I think you don't understand how valsort works. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: preserve value order with referential integrity overlay?
--On Wednesday, August 15, 2007 8:02 AM -0700 Quanah Gibson-Mount [EMAIL PROTECTED] wrote: --On Wednesday, August 15, 2007 9:07 AM +0800 Zhang Weiwu [EMAIL PROTECTED] wrote: Thanks. I already read a bit about valsort before I posed the original message, I think you mean to re-format the values like this: nationality: 1 DE nationality: 2 CN I think it really should work for me except I am going to need ordered values in DN syntax companyRepresentative: 1 cn=John,... companyRepresentative: 2 cn=Paul,... I am not sure if I can re-format string representation of DN (likely not) so I'd try Chu's solution first to see if it works. I think you don't understand how valsort works. Although for the attribute being used by valsort, it'd probably have to be something other than DN syntax, although the client querying it wouldn't have to know that (just to note). Not sure how that may or may not affect matching rules. But the point is to the client, unless it exerts the control, it doesn't see the weights, just ordered results. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: preserve value order with referential integrity overlay?
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. 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. 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. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: preserve value order with referential integrity overlay?
在 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...
Re: preserve value order with referential integrity overlay?
Zhang Weiwu wrote: 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. against the specs, which warned you about not relying on this. Later we used businessCategory which also have strict order requirements and that worked several years. same as above. 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 actually, the theory taught you not to do so. 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. Trial and error may be good when you have no alternatives. I understand LDAP may have a steep learning curve when non-trivial things need to be dealt with. So I'd recommend you take this opportunity to give up bad habits based on experience and try to stick with specs, instead of trying to force OpenLDAP into letting you preserve them. In the LDAP world, you'd need to define your own myPreferredTelephoneNumber and put the preferred telephone number there as well as in the telephoneNumber, so that it can be collected both ways. Or, if the dumbest client you need to stick with is the one that wants the preferred number in the telephoneNumber attribute, leave it there, and add a myAlternateTelephoneNumber containing the perferred as well as the non preferred ones. Going down the X-ORDERED trail would probably mean lots of pain. We needed to introduce it as a quick and reliable way to force ordering for internal purposes, but it is very unlikely that normal clients (I mean: clients whose sources you can't or don't want to modify) will be willing to cooperate with it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: [EMAIL PROTECTED] ---
Re: preserve value order with referential integrity overlay?
--On Tuesday, August 14, 2007 5:23 PM +0800 Zhang Weiwu [EMAIL PROTECTED] wrote: Yeah very helpful source of information. I am reading it and hope to find a solution... The valsort overlay in OpenLDAP, of course. Although you'll need to define a custom attribute to hold the values for it, and you can't index them for searching, currently (or at least not for eq type searches in a meaningful way). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: preserve value order with referential integrity overlay?
Zhang Weiwu wrote: One dump question, the draft you composed expires at end of 2006, does that mean this draft will no longer become RFC and (thus?) have no implementation yet? The draft is intended to document what we've already implemented in OpenLDAP. The OpenLDAP implementation will continue to exist regardless of the document status. There are some flaws/errors in that draft that make it unsuitable for general purpose usage. I haven't had time to address those points, and since what we have already works for us, I haven't had much incentive to make time for it. Having to require client modification might be the big reason to not having it implemented, I guess. 在 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. 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. 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. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: preserve value order with referential integrity overlay?
One dump question, the draft you composed expires at end of 2006, does that mean this draft will no longer become RFC and (thus?) have no implementation yet? Having to require client modification might be the big reason to not having it implemented, I guess. 在 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. 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. 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.
Re: preserve value order with referential integrity overlay?
I don't want to make this longer than necessary, but if you have a table
favourite_drink
person_id, drink
containing
'ando' 'coke'
'ando' 'beer'
and you
delete from favourite_drink where person_id='ando' and drink='coke';
and
insert into favourite_drink (person_id,drink) values ('ando','wine');
I'm pretty confident 'wine' will not come before 'beer', even if 'wine' is
what I really prefer.
In this sense, I think LDAP was designed to be almost as dumb as most
applications (and application developers) but not dumber. So, values with
the very same importance go into sets, and values with special importance
go into specific attributes, possibly with SINGLE-VALUE constraint if
appropriate, as I explained in my previous message.
As a general rule, don't ask software to do what can be better done by
yourself, and viceversa :)
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: [EMAIL PROTECTED]
---
preserve value order with referential integrity overlay?
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. The value of the data is almost rely on the order of the values, and I used referential integrity overlay without first checking if it preserve the order of values my discovery: referential integrity overlay always puts the last modified value at the bottom. e.g. companyRepresentative: cn=David Jone,ou=sales,o=example.com companyRepresentative: cn=John Carmack,ou=development,o=example.com Now if David Jone is renamed to David Jones because people find his name is misspelled, then after modrdn operation, the result is: companyRepresentative: cn=John Carmack,ou=development,o=example.com companyRepresentative: cn=David Jones,ou=sales,o=example.com So people begin to contact John Carmack for all affairs. 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, or 2) try to use several attributes like FirstCompanyRepresentative, SecondCompanyRepresentative, ThirdCompanyRepresentative -- 锐业软服（国内业务） http://www.realss.cn Real SoftService http://www.realss.com 销售咨询(Sales Department):0086 592 20 99987 (Chinese, German, English) 国际业务(International Sales): 0086 10 8460 6011 (German and English) 联系：厦门大学科技园，嘉庚二号楼6楼 邮政：厦门大学2312号信箱（邮编361005）
Re: referential integrity (patch included)
Emmanuel Dreyfus wrote: On Fri, May 25, 2007 at 06:55:16PM -0700, Howard Chu wrote: I have been reading the docs, looking for a way to acheive referential integrity as it is done in RDBMS. Write a new overlay to do what you want... I modified slapo-constraint to get the feature I needed: it is now able to verify that an attribute value is bound to the existing values of another attribute. Attached is a draft patch for review. It works, but there are a few things I have been doing without really knowing if it was correct or not, so it might be working by accident :-) Is there something wrong in this code? Then there is the UI question. For now it's configured in slapd.conf like this: databasebdb suffix dc=example,dc=net overlay constraint constraint_attribute title key netExampleTitle Which means that add and modify on title will fail if the new value is not an existing netExampleTitle value. I used the keyword key with RDBMS referential integrity in mind, but I'm not sure it's that clear in this context. Suggestions are welcome. The update to man page is missing yet. I know. Also, I had trouble understanding the style used in these sources. Is there an official style guide for OpenLDAP? Did you see http://www.openldap.org/devel/contributing.html If the approach is okay, I'll make an updated patch based on feedback to this one and file an ITS with it. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E [EMAIL PROTECTED] Open Source. Open Solutions(tm). http://www.suretecsystems.com/
Re: referential integrity (patch included)
Pierangelo Masarati [EMAIL PROTECTED] wrote: I modified slapo-constraint to get the feature I needed: it is now able to verify that an attribute value is bound to the existing values of another attribute. Please provide patches thru the ITS http://www.openldap.org/its/ . My patch has been burried in ITS#4987, no feedback on it? I doubt it means it's just perfect :-) -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz [EMAIL PROTECTED]
Re: referential integrity (patch included)
Pierangelo Masarati [EMAIL PROTECTED] wrote: Please provide patches thru the ITS http://www.openldap.org/its/ . Here it is: ITS #4987 -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz [EMAIL PROTECTED]
Re: referential integrity (patch included)
On Fri, May 25, 2007 at 06:55:16PM -0700, Howard Chu wrote: I have been reading the docs, looking for a way to acheive referential integrity as it is done in RDBMS. Write a new overlay to do what you want... I modified slapo-constraint to get the feature I needed: it is now able to verify that an attribute value is bound to the existing values of another attribute. Attached is a draft patch for review. It works, but there are a few things I have been doing without really knowing if it was correct or not, so it might be working by accident :-) Is there something wrong in this code? Then there is the UI question. For now it's configured in slapd.conf like this: databasebdb suffix dc=example,dc=net overlay constraint constraint_attribute title key netExampleTitle Which means that add and modify on title will fail if the new value is not an existing netExampleTitle value. I used the keyword key with RDBMS referential integrity in mind, but I'm not sure it's that clear in this context. Suggestions are welcome. The update to man page is missing yet. I know. Also, I had trouble understanding the style used in these sources. Is there an official style guide for OpenLDAP? If the approach is okay, I'll make an updated patch based on feedback to this one and file an ITS with it. -- Emmanuel Dreyfus [EMAIL PROTECTED]
Re: referential integrity (patch included)
On Mon, May 28, 2007 at 08:26:07PM +, Emmanuel Dreyfus wrote:
Attached is a draft patch for review.
And as usual, the patch was missing. Here it is
--
Emmanuel Dreyfus
[EMAIL PROTECTED]
diff -r -U4 openldap-2.4.4alpha.orig/servers/slapd/overlays/constraint.c
openldap-2.4.4alpha/servers/slapd/overlays/constraint.c
--- openldap-2.4.4alpha.orig/servers/slapd/overlays/constraint.c
2007-02-13 20:22:29.0 +
+++ openldap-2.4.4alpha/servers/slapd/overlays/constraint.c 2007-05-28
20:10:48.0 +
@@ -1,8 +1,9 @@
/* constraint.c - Overlay to constrain attributes to certain values */
/*
*
* Copyright 2003-2004 Hewlett-Packard Company
+ * Copyright 2007 Emmanuel Dreyfus
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
@@ -12,9 +13,10 @@
* top-level directory of the distribution or, alternatively, at
* http://www.OpenLDAP.org/license.html.
*/
/*
- * Author: Neil Dunbar [EMAIL PROTECTED]
+ * Authors: Neil Dunbar [EMAIL PROTECTED]
+ * Emmannuel Dreyfus [EMAIL PROTECTED]
*/
#include portable.h
#ifdef SLAPD_OVER_CONSTRAINT
@@ -36,8 +38,9 @@
* control the add and modify value mods of a modify)
*/
#define REGEX_STR regex
+#define KEY_STR key
/*
* Linked list of attribute constraints which we should enforce.
* This is probably a sub optimal structure - some form of sorted
@@ -50,8 +53,9 @@
struct constraint *ap_next;
AttributeDescription *ap;
regex_t *re;
char *re_str; /* string representation of regex */
+AttributeDescription *ap_key;
} constraint;
enum {
CONSTRAINT_ATTRIBUTE = 1
@@ -65,8 +69,14 @@
( OLcfgOvAt:13.1 NAME 'olcConstraintAttribute'
DESC 'regular expression constraint for attribute'
EQUALITY caseIgnoreMatch
SYNTAX OMsDirectoryString ), NULL, NULL },
+{ constraint_attribute, attribute key attribute name,
+ 4, 4, 0, ARG_MAGIC | CONSTRAINT_ATTRIBUTE, constraint_cf_gen,
+ ( OLcfgOvAt:13.1 NAME 'olcConstraintAttribute'
+ DESC 'attribute value constraint for attribute'
+ EQUALITY caseIgnoreMatch
+ SYNTAX OMsDirectoryString ), NULL, NULL },
{ NULL, NULL, 0, 0, 0, ARG_IGNORED }
};
static ConfigOCs constraintocs[] = {
@@ -95,15 +105,25 @@
case CONSTRAINT_ATTRIBUTE:
for (cp=cn; cp; cp=cp-ap_next) {
int len;
char *s;
+ char *tstr = NULL;
+ char *vstr = NULL;
-len = cp-ap-ad_cname.bv_len +
-strlen( REGEX_STR ) + strlen( cp-re_str) + 3;
+ if (cp-re) {
+ tstr = REGEX_STR;
+ vstr = cp-re_str;
+ } else if (cp-ap_key) {
+ tstr = KEY_STR;
+ vstr = cp-ap_key-ad_cname.bv_val;
+ }
+
+len = cp-ap-ad_cname.bv_len
+ + strlen(tstr) +
strlen(vstr); + 3;
s = ch_malloc(len);
if (!s) continue;
snprintf(s, len, %s %s %s, cp-ap-ad_cname.bv_val,
- REGEX_STR, cp-re_str);
+ tstr, vstr);
bv.bv_val = s;
bv.bv_len = strlen(s);
rc = value_add_one( c-rvalue_vals, bv );
if (rc) return rc;
@@ -174,9 +194,17 @@
%s: %s\n, c-log, c-msg, 0 );
return( ARG_BAD_CONF );
}
-if ( strcasecmp( c-argv[2], regex ) == 0) {
+if ( strcasecmp( c-argv[2], KEY_STR ) == 0) {
+ if ( slap_str2ad( c-argv[3], ap.ap_key, text ) )
{
+ snprintf( c-msg,
sizeof( c-msg ),
+ %s %s:
%s\n, c-argv[0], c-argv[3], text );
+ Debug( LDAP_DEBUG_CONFIG|LDAP_DEBUG_NONE,
+ %s: %s\n, c-log, c-msg, 0 );
+ return( ARG_BAD_CONF );
+ }
+ } else if ( strcasecmp( c-argv[2], REGEX_STR ) == 0) {
int err;
ap.re = ch_malloc( sizeof(regex_t) );
if ((err = regcomp( ap.re,
@@ -208,8 +236,9 @@
a2-ap_next = on-on_bi.bi_private;
a2-ap = ap.ap;
a2-re = ap.re;
a2-re_str = ap.re_str;
+a2-ap_key = ap.ap_key;
Re: referential integrity (patch included)
Emmanuel Dreyfus wrote: I modified slapo-constraint to get the feature I needed: it is now able to verify that an attribute value is bound to the existing values of another attribute. Please provide patches thru the ITS http://www.openldap.org/its/ . p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: [EMAIL PROTECTED] ---
referential integrity
Hello I have been reading the docs, looking for a way to acheive referential integrity as it is done in RDBMS. For instance, if I want to constraint the value of atribute title to a set of value, so that any modification to a value not in the list would be denied. Let's say the set of legal values could be stored in the directory, ad objects of a dedicated class; How can it be done? slapo-refint is not about denying changes, slapo-constraint can only enforce regex matching.. Is there anything else I missed? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz [EMAIL PROTECTED]
Re: referential integrity
Emmanuel Dreyfus wrote: Hello I have been reading the docs, looking for a way to acheive referential integrity as it is done in RDBMS. For instance, if I want to constraint the value of atribute title to a set of value, so that any modification to a value not in the list would be denied. Let's say the set of legal values could be stored in the directory, ad objects of a dedicated class; How can it be done? slapo-refint is not about denying changes, slapo-constraint can only enforce regex matching.. Is there anything else I missed? Write a new overlay to do what you want... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: referential integrity
Howard Chu [EMAIL PROTECTED] wrote: Write a new overlay to do what you want... Right, I just wanted confirmation that 1) nothing exists yet to do it 2) the idea is not heretic I'll have a look at it. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz [EMAIL PROTECTED]
