Page History

...

Introduction

We will discuss various ways to store lists of simple Java types in LDAP.  LDAP is particularly poor at managing lists.  Lists of primitive types require the maintenance of order.  Simply using a multivalued attributeType does not solve this problem since there is no way to determine the order of the values.  Workarounds can be used each with trade offs.  One workaround may be better than another for certain circumstances.  In any case though, an understanding of how the directory will be used (searched) will factor into the selection of the best workaround.  Any persistence engine mapping Java bean list properties to LDAP should allow for several mechanisms chosen at the user's discretion.

...

Again this has the same issue regarding proper syntax usage and the need to use poor substring assertions to locate foo entries with a particular bar value.  Here the position of the list element in the value of the attribute determines it's index.  However the performance degrades rapidly as the list grows: the cost of parsing, validating and inserting into the value increases as does the memory and transfer times.unmigrated-wiki-markup

Lists of primitives can also be modeled as subordinate entries containing an index attribute and a value attribute for the list element value.   If these entries are immediately subordinate to foo they can use an RDN that is based fully or in part on the index attribute.  The RDN can be single attribute or multi-attribute based as a composite RDN.  Using the index attribute alone as the single RDN attribute is a bit dangerous since this may collide with any other List property in foo.  Using the index attribute value with a bar \[post\|pre\]fix for a single RDN attribute prevent collisions with other list properties.  The best solution with subordinate entries for list properties is to create a container for the list property where the RDN value of the container entry is the name of the property then the container houses entries with index and value attributes for elements.  The problem with any of these subordinate entry approaches for List based properties is the amount of traffic. Each list element is an entry requiring a SearchResponseEntry LDAP response to the client.    If these entries are immediately subordinate to foo they can use an RDN that is based fully or in part on the index attribute.  The RDN can be single attribute or multi-attribute based as a composite RDN.  Using the index attribute alone as the single RDN attribute is a bit dangerous since this may collide with any other List property in foo.  Using the index attribute value with a bar [post|pre]fix for a single RDN attribute prevent collisions with other list properties.  The best solution with subordinate entries for list properties is to create a container for the list property where the RDN value of the container entry is the name of the property then the container houses entries with index and value attributes for elements.  The problem with any of these subordinate entry approaches for List based properties is the amount of traffic. Each list element is an entry requiring a SearchResponseEntry LDAP response to the client. 

With subordinate entries used for lists search operations still have issues however the issues are different.  Asking for a foo object with a dog value in the bar List property is still a hassle.  We would have to find all bar entries will value 'dog' then the client would have to sort through them to make sure they correspond to foo objects. Since other objects besides foo can also have bar properties the client cannot presume the returned bar objects correspond to foo based bar values.  Furthermore it's a pain to figure out which foo object the bar value corresponds to without utilizing the DN and that may not help unless the DN contains a directory unique identifier for the foo object.