[#DIRSERVER-254] Search for super OC does not return subclasses if add op does not add complete objectClass lineage

Directory ApacheDS

Search for super OC does not return subclasses if add op does not add complete objectClass lineage

Created: 18/Oct/05 10:54 AM Updated: 10/Feb/06 12:26 PM

Return to search

Component/s:

None

Affects Version/s:

pre-1.0

Fix Version/s:

1.0-RC1

Time Tracking:

Not Specified

Resolution Date:

07/Feb/06 04:23 AM

Description

« Hide

If I add an entry with objectClass inetOrgPerson to the directory but do not include in the objectClass attribute values for the super objectClasses like organizationalPerson and person then (objectClass=person) will not return the entry when it is in scope. To fix this is simple. Instead of adding tests for lineage on search operations which would be a nightmare we should pay the price on the add operation. Basically an interceptor can check that the lineage of objectClasses is present within the objectClass attribute. If not then it can be injected into the entry before the add operation takes place.

I don't know if this is correct behavior but it cannot hurt.

All

Comments

Work Log

Change History

Subversion Commits

Sort Order:

Alex Karasulu made changes - 18/Oct/05 10:56 AM

Field	Original Value	New Value
Description	If I add an entry with objectClass inetOrgPerson to the directory but do not include in the objectClass attribute values for the super objectClasses like organizationalPerson and person then (objectClass=person) will not return the entry when it is in scope. To fix this is simple. Instead of adding tests for lineage on search operations which would be a nightmare we should pay the price on the add operation. Basically an interceptor can check that the lineage of objectClasses is present within the objectClass attribute.	If I add an entry with objectClass inetOrgPerson to the directory but do not include in the objectClass attribute values for the super objectClasses like organizationalPerson and person then (objectClass=person) will not return the entry when it is in scope. To fix this is simple. Instead of adding tests for lineage on search operations which would be a nightmare we should pay the price on the add operation. Basically an interceptor can check that the lineage of objectClasses is present within the objectClass attribute. If not then it can be injected into the entry before the add operation takes place. I don't know if this is correct behavior but it cannot hurt.

Alex Karasulu made changes - 18/Oct/05 11:04 AM

Fix Version/s		0.9.4 [ 12310230 ]
Fix Version/s	0.9.3 [ 12310193 ]

Stefan Zoerner made changes - 19/Oct/05 03:31 AM

Comment

[ There are different options for a server to act, if a user adds an entry, where objectClasses are missing, like this one (comparable to your example)

dn: cn=Kate Bush,dc=apache,dc=org
objectClass: top
objectClass: person
sn: Bush
cn: Kate Bush

I am not sure whether it is defined by the standard, how to react, but here are the options I found with example implementations (if I found any).

(1) Just add it as is. That is, the corresponding entry looks exactly like above (plus operational attributes)
Example for a server which acts like this:
OpenLDAP 2.1

(2) Fill the missing objectClasses during the add, resulting in an entry which looks like this:

dn: cn=Kate Bush,dc=apache,dc=org
objectClass: top
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
sn: Bush
cn: Kate Bush

Examples for a server which behaves like that:
Sun Java System Directory Server 5.2
IBM Tivoli Directory Server 6.0
Active Directory Application Mode (ADAM) (but it adds other classes as above)
Novell eDirectory 8.7.3

(3) Refuse to add the entry, e.g. with an error code for Schema Violation.
Examples for a server which behaves like that:
(none found yet)

I recommend application developers not to add such an entry, and then they do not face these different server reactions.

For our situation, I would recommend to implement (2) -- just as you suggested. (3) is better than (1) from my point of view, because people like to search by base classes, and it can't be up to us to check the whole hierarchy within a search operation (to expensive). ]

Alex Karasulu made changes - 03/Feb/06 05:01 AM

Status

Open [ 1 ]

In Progress [ 3 ]

Alex Karasulu made changes - 07/Feb/06 04:23 AM

Resolution		Fixed [ 1 ]
Status	In Progress [ 3 ]	Closed [ 6 ]

Alex Karasulu made changes - 10/Feb/06 12:26 PM

Project	Directory Server [ 10516 ]	Directory ApacheDS [ 12310260 ]
Affects Version/s		pre-1.0 [ 12310782 ]
Fix Version/s	1.0-RC1 [ 12310230 ]
Fix Version/s		1.0-RC1 [ 12310780 ]
Key	DIREVE-276	~~DIRSERVER-254~~