directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] Commented: (DIRSERVER-824) Collective attributes are not evaluated in search operations when they are used in filter expressions
Date Fri, 12 Jan 2007 19:03:27 GMT


Emmanuel Lecharny commented on DIRSERVER-824:

Injecting the collective attributes in the entry before storing the data will be shouting
you in the feet : this is exactly what CA have been creating to  : to avoid such duplication
of data.

Now, having said that does not help at all to solve the pb ! (sorry :)

The good point is that filtering on CA helps a lot : you can discard a full branch if the
c-l is not found in the subentry. But this can also becoming a hell, if the subtree selection
is a complex one...

Now, what about doing something which is close to the idea you had :
- adding CA to the selected entries, before discarding or returning them ?

Suppose you select with a filter like (&(ObjectClass=person)(c-l=ankara)), and you get
the entry :
dn: uid=ersiner,c=turkey,ou=people,dc=apache,dc=org
objectclass: top
objectclass: person
uid: ersiner

in the c=turkey,ou=people,dc=apache,dc=org associated subtree you have a c-l: ankara
now you clone the entry, add c-l= ankara, then apply the filters, then if it matches, return
the entry

wdyt ?

> Collective attributes are not evaluated in search operations when they are used in filter
> -----------------------------------------------------------------------------------------------------
>                 Key: DIRSERVER-824
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Bug
>    Affects Versions: 1.0.1, 1.5.0
>            Reporter: Ersin Er
> As collective attributes never hit the database, they are not evaluated upon search operations
if they are used in filters. This is an hard issue to fix but we may also support this kind
of virtual attributes in the future, so we need a way to handle such cases. One solution can
be injecting the collective attributes into entries before search operations. Other LDAP servers
may be doing this. (I had felt this when I read their documents.) Hoever I am not sure about
the negative effects of that way on performance.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message