directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [LDAP DAS] Efficient Updating of Persisted Objects
Date Tue, 27 Mar 2007 15:28:28 GMT
Ole,

On 3/21/07, Ole Ersoy <ole.ersoy@gmail.com> 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.  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.

http://bsd.cs.cofc.edu/Java/Javadocs1.5/api/javax/naming/directory/DirContext.html#modifyAttributes(javax.naming.Name,
int, javax.naming.directory.Attributes)



> 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?

Alex

Mime
View raw message