the key attribute is used for both interal caching of the object as for looking up the object.
eg: specify the cn as primary key:
If you have a structured tree, where multiple objects can have the same cn, the caching mechanism is using the cn, and thus loading the object from cache, even if the dn of the object is different.
Resolution: the caching should use the DN, and not the key. In LDAP, the key is unique within a given context, not within a given object class (unlike databases, where the primary key is unique for a given table). Databases do not know the concept of context.
If we would be able to specify the dn as a key (see issue NUCLDAP-49
), the caching mechanism works, but queries to the LDAP will be done as if the dn was a normal attribute, executing a query like (&(dn=cn=aaa,ou=bbb,o=ccc)) which does not work.
I also tried using the GUID of an object, but the interface seems unable to load base64 strings (the valus is always null). Also searches on this are different (eg: GUID=\0A\12\AF).