directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: [LDAP DAS] Efficient Updating of Persisted Objects
Date Wed, 28 Mar 2007 05:03:33 GMT
Alex Karasulu wrote:
> Ole,
> On 3/21/07, *Ole Ersoy* < 
> <>> wrote:
>     Hey Guys,
>     Just wanted to see if anyone had any thoughts on handling updates
>     to Java beans (Service Data Objects - but basically the same thing)
>     persisted with ADS.
>     With Service Data Objects we create a datagraph that is then
>     disconnected
>     from it's persistence source and we can mutate it.  Then later we
>     want to
>     persist the graph.  Each object in the graph has a change summary,
>     that
>     stores the fields that were updated.
> This change summary is very interesting.  I had experimented with 
> something
> similar which David Jencks did not like too much.  Basically the 
> modifier pattern
> was being used to track modifications to attributes of entities.  It 
> was tracking
> the set of modify add, remove, and replace operations to perform on 
> each attribute.
>     This makes it possible to only update objects that have been
>     changed, and
>     we only need to update the fields that were changed. 
> Exactly this is what I was doing in this one admin API I had in triplesec.
>     However, I think the DirContext will overwrite the entire
>     object during the bind operation, rather than updating specific
>     fields
>     on the object.  
> Hmmm with heirarchical services in JNDI you should not be using 
> bind().  You
> should be using the createSubcontext() and modifyAttributes() methods 
> instead. 

Oh OK.  My impression was that I would use createSubcontext() when
creating a new context for a serialized java object for example.

Let me give an exampel - I'll be starting the DAS "serious" work tomorrow,
so if I'm off on this, I'll eventually find out :-), but this may help 
the conversation with respect to updating attributes vs. the entire object.

Suppose my initial context is:

|uid=ole,ou=users, ou=system

And I wanted to add a sub context for an Instance of MyClass
with reference named myClassInstance

I could do something like


Which would create the context:

|cn=myClassInstance, uid=ole, ou=users, ou=system|

Then to store a my serialized myClassInstance under this dn in a
javaSerializedData attribute, I would do something like this:

|||String bindContext = "cn=|myClassInstance|,uid=ole,ou=users, 

|ctx.bind( bindContext, ||nameOfMyObject||)

I'm also guessing that the bind operation would take care
of the createSubcontext() step for me, ... but anyways...


> You
> might want to go through the JNDI tutorial for LDAP just to get a good 
> feel for how to
> work with non-flat namespaces using JNDI.  Namely with LDAP you don't 
> need to
> rebind the object with a modification to an attribute.  This is what 
> the modify
> operations are for.

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.


> <>,

> int,
Cool - I'll have a looksee - I've been using the articles on the 
ApacheDS website as a reference so far, but the more material the better.

>     Initially I  was thinking that the object's attributes (primitive
>     properties - not references to other objects)
>     would be serialized and made into directory attributes.  But I think a
>     LDAP ObjectClass schema that corresponds to the
>     object's class (The class of the object we are persisting) would
>     have to
>     be generated and stored along with the instance.
>     This might lead to performance improvments, if doable...?
>     Thoughts?
> 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

I create an instance of UserClass called userClass.

The I do

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.
> Alex
- Ole

View raw message