LDAP Datastores

DataNucleus supports persisting/retrieving objects to/from LDAP datastores
(using the datanucleus-ldap plugin).
If you wish to help out development of this plugin either by contributing or by sponsoring particular
functionality please contact us via the DataNucleus Forum.

Datastore Connection

The following persistence properties will connect to an LDAP running on your local machine

Queries

Access Platform allows you to query the objects in the datastore using the following

JDOQL - language based around the objects that are persisted and
using Java-type syntax

JPQL - language based around the objects that are persisted and
using SQL-like syntax

Queries are evaluated in-memory.

Mapping : LDAP Datastore Mapping

When persisting a Java object to an LDAP datastore clearly the user would like some control
over where and how in the LDAP DIT (directory information tree) we are persisting the object.
In general Java objects are mapped to LDAP entries and fields of the Java objects are mapped
to attributes of the LDAP entries.

The following Java types are supported and stored as single-valued attribute to the LDAP entry:

Arrays, Collections, Sets and Lists of these data types are stored as multi-valued attributes.
Please note that when using Arrays and Lists no order could be guaranteed and no duplicate values are allowed!

Mapping : Relationships

By default persistable objects are stored as separate LDAP entries. There are some options how to
persist relationship references between persistable objects:

It is also possible to store persistable objects embedded.
Note that there is inbuilt logic for deciding which of these mapping strategies to use for a relationship. You can explicitly set this with the
metadata extension for the field/property mapping-strategy and it can be set to dn or attribute.

For the class as a whole we use the table attribute to set the distinguished name
of the container under which to store objects of a type. So, for example, we are mapping all
objects of class Group as subordinates to "ou=Groups,dc=example,dc=com".
You can also use the extension "dn" to specify the same thing.

For the class as a whole we use the schema attribute to define the object classes
of the LDAP entry. So, for example, all objects of type Person are mapped to the
common "top,person,organizationalPerson,inetOrgPerson" object classes in LDAP.
You can also use the extension "objectClass" to specify the same thing.

For each field we use the column attribute to define the LDAP attribute that
we are mapping this field to. So, for example, we map the Group "name" to "cn" in our LDAP.
You can also use the extension "attribute" to specify the same thing.