Re: Filter on higher rdn and read lower rdn attributes

["S.A." <qmt9z3@yahoo.com>]

--- 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