Alex Karasulu wrote:
Ole,
On 3/21/07, *Ole Ersoy* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
facilitate
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
ctx.createSubcontext("cn=myClassInstance");
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,
ou="system";|
|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.
http://bsd.cs.cofc.edu/Java/Javadocs1.5/api/javax/naming/directory/DirContext.html#modifyAttributes(javax.naming.Name
<http://bsd.cs.cofc.edu/Java/Javadocs1.5/api/javax/naming/directory/DirContext.html#modifyAttributes%28javax.naming.Name>,
int, javax.naming.directory.Attributes)
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
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?
|
WDYT?
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
