Hello,
I have a question regarding the construction of search filter (assuming that what I think is possible in LDAP).
For a tree shown like below:
o dc=com | o dc=xyz / | | \ ou=machines o . . . . . o ou=people / | \ uid=abby o . . o ou=xie <- OC1 / ou=options o <- OC2 / ou=theme1 o <- OC3
OC1 != OC2 != OC3 (objectclasses with different set of attributes)
Assume that at uid=<name> rdn, the objectclass (OC1) has an attribute called accessFlag. Based on this accessFlag attribute value, is it possible to construct a search filter that will give us the attributes of the objectclass (OC3) with rdn ou=<theme name>?
That is, I want to get the theme values of all users whose accessFlag is set to some value.
Thank you!
Hello,
I have a question regarding the construction of search filter (assuming that what I think is possible in LDAP).
For a tree shown like below:
o dc=com | o dc=xyz / | | \ ou=machines o . . . . . o ou=people / | \ uid=abby o . . o ou=xie <- OC1 / ou=options o <- OC2 / ou=theme1 o <- OC3OC1 != OC2 != OC3 (objectclasses with different set of attributes)
Assume that at uid=<name> rdn, the objectclass (OC1) has an attribute called accessFlag. Based on this accessFlag attribute value, is it possible to construct a search filter that will give us the attributes of the objectclass (OC3) with rdn ou=<theme name>?
That is, I want to get the theme values of all users whose accessFlag is set to some value.
In short, this is not possible.
As a more articulate response, I'd note this type of behavior is occasionally needed, and should be implemented at the application level. For this purpose, I have drafted in the past a formal specification of a search control that allows to specify the parameters of a subsearch to be applied to all entries returned by the primary search. This specification was never submitted for many reasons and unfortunately it was never implemented. I might try to dig out what I wrote, in case someone finds it interesting and worth reviving and implementing.
p.
--- On Sun, 9/19/10, masarati@aero.polimi.it masarati@aero.polimi.it wrote:
From: masarati@aero.polimi.it masarati@aero.polimi.it Subject: Re: Filter on higher rdn and read lower rdn attributes To: "S.A." qmt9z3@yahoo.com Cc: openldap-technical@openldap.org Date: Sunday, September 19, 2010, 3:50 PM
Hello,
I have a question regarding the construction of search
filter
(assuming that what I think is possible in LDAP).
For a tree shown like below:
o dc=com
|
o dc=xyz
/ | | \
ou=machines o
. . . . . o ou=people
/ | \
uid=abby o . . o ou=xie <- OC1
/
ou=options o <- OC2
/
ou=theme1 o <- OC3
OC1 != OC2 != OC3 (objectclasses with different set of
attributes)
Assume that at uid=<name> rdn, the objectclass
(OC1) has an attribute
called accessFlag. Based on this accessFlag attribute
value, is it
possible to construct a search filter that will give
us the attributes
of the objectclass (OC3) with rdn ou=<theme
name>?
That is, I want to get the theme values of all users
whose accessFlag
is set to some value.
In short, this is not possible.
As a more articulate response, I'd note this type of behavior is occasionally needed, and should be implemented at the application level. For this purpose, I have drafted in the past a formal specification of a search control that allows to specify the parameters of a subsearch to be applied to all entries returned by the primary search. This specification was never submitted for many reasons and unfortunately it was never implemented. I might try to dig out what I wrote, in case someone finds it interesting and worth reviving and implementing.
p.
Thanks for your response!
Under the circumstance, I am thinking that one way to go about getting the required attribute data is to add 'accessFlag' attribute at the required rdn. This is going to be duplicate piece of data and any updates to 'accessFlag', would now result in two updates. However, I will be able to save multiple reads. In my scenario, we do lot more reads than the updates on the 'accessFlag' field.
Is there a better way to deal with the above case?
Thanks
Under the circumstance, I am thinking that one way to go about getting the required attribute data is to add 'accessFlag' attribute at the required rdn. This is going to be duplicate piece of data and any updates to 'accessFlag', would now result in two updates. However, I will be able to save multiple reads. In my scenario, we do lot more reads than the updates on the 'accessFlag' field.
If you're confident you can keep those flags in sync, then it's probably the easiest way to go.
p.
openldap-technical@openldap.org
-
masarati＠aero.polimi.it -
S.A.