directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Re: [LDAP DAS] Efficient Updating of Persisted Objects
Date Wed, 28 Mar 2007 19:42:56 GMT

Ole Ersoy schrieb:
> Just want to make sure we are talking about the same thing here.
> We may have some attributes stored in ADS under:
> |DN: uid=ole,ou=users, ou="system
> This DN has the Person ObjectClass associated with it.
> So I may wish to change one of the attributes (The password attribute
> for instance)
> that are associated with the Person ObjectClass.
> Then I could see using a modify operation.
> Is that also the case when storing entire javaObjects
> in a javaSerializedData attribute?
> |I just want to make sure we are clearly separating java object
> attributes (Primitive java class members)
> from LDAP attributes.
> Let me stop here in case I'm making any sense?
> If not hopefully once I'm done writing the design guide and get a
> terminology and concept section going
> things will be a little clearer.

What kind of storage are you thinking of? Saving the entire SDO in the
javaSerializedData or saving the attributes of the SDO?

When storing entire java objects using the javaSerializedData attribute
the whole serialized object is transmitted over the wire and stored as
binary (BLOB). This is a generic way to save any type of serializable
object into a directory. But only Java programs could read this object
from directory again, other programming languages could not handle these
objects. Sun's JNDI LDAP provider uses the javaObject object class and
the javaSerializedData, see RFC2713.

To allow interoperability with other languages is would be better to
save objects as entries with attributes, maybe using a custom schema
with special object classes and attribute types. Then of course a
mapping between the java classes and attributes and the LDAP object
classes and attribute types is needed.

>> Hmmm I think some of your premisses in this question may be due to
>> considering the use
>> of bind() instead of using modifyAttributes() and createSubcontext(). 
>> If you use these methods
>> I think there is no further preformance issue to consider.  WDYT?
> Ahh - This is the part where I need clarification.
> If we serialize an entire object to ApacheDS, then we have to get it
> from ApacheDS,
> update it, and send it back to be stored in a javaSerializedData
> attribute right?


> For instance I may have a Class called UserClass with a String member
> userName.
> I create an instance of UserClass called userClass.
> The I do
> userClass.setUserName("ole");
> Now I want to store userClass in ADS here:
> |DN: cn=|userClass|,ou=users, ou="system
> So I do this:
> ||String bindContext = "cn=|myClassInstance|,ou=users, ou="system";|
> |ctx.bind( bindContext, ||userClass||);
> Now userClass is in ADS stored as a javaSerializedData LDAP attribute
> value,
> hanging off of the bindContext I specified.
> Later when I want to update
> the userName member of the UserClass instance I serialized to ADS,
> I need to use JNDI to load the instance again right?
> Then update userName.  Then serialize userClass back to ADS again?
> |
> I mentioned some stuff about generating an ObjectClass schema that is
> the LDAP schema of the Java Class UserClass,
> so that the primitive members (That have java primitive types) would be
> stored as LDAP atttributes rather than storing the entire
> object as a single javaSerializedData attribute attached to a DN.  I'll
> hold off on commenting more in case I'm getting warmer.

Yeah, I think that would be the better approach.

I also think that the LDAP DAS isn't limited to ApacheDS as backend. Any
 LDAP directory could be used as backend.


View raw message