Issue Details (XML | Word | Printable)

Key: NUCLDAP-52
Type: Bug Bug
Status: Open Open
Priority: Testcase Required Testcase Required
Assignee: Stefan Seelmann
Reporter: Stefaan Van Cauwenberge
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
DataNucleus Store LDAP

key is used for both internal (caching key) and external (object lookup), preventing the interface work well when multiple objects have the same 'key'

Created: 11/May/12 03:27 PM   Updated: 09/Aug/12 09:54 AM
Component/s: None
Affects Version/s: 3.1.0.m3
Fix Version/s: None

Environment: all

Datastore: LDAP
Severity: Proof of Concept


 Description  « Hide
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:
            <field
                  name="commonName"
                  persistence-modifier="persistent"
                  primary-key="true"
                  column="cn"/>

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

Stefaan

Stefaan

Sort Order: Ascending order - Click to sort in descending order
There are no comments yet on this issue.