David,
The LDAP DAS should work exactly the same way an RDB DAS would work.
So from the SDO point of view (Or your java bean point of view) it does
not really
matter where the data is being persisted.
It could go to an XML file(s), an RDB, ADS, ERP, ..... It just depends on
which DAS the SDO datagraph is being serialized with.
I'm going to start writing the DAS design docs tomorrow, starting with
conventions used to perform CRUD against ADS for an SDO datagraph,
so hang in there. I'm 99.9% sure that it does everything you want it to
and more,
but the proof is in the pudding, and I would like you to be able to
judge for yourself,
so I'll hurry it up.
Cheers,
- Ole
David Jencks wrote:
On Mar 27, 2007, at 11:28 AM, 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.
What I didn't like was that you were keeping track of the
modifications outside the POJO-like data object itself in (IMO) very
hard to use helper objects, and you didn't write a framework. I took
essentially the same idea and came up with something pretty similar to
jpa/jdo, where you have things that look like POJOs to the outside
world, but inside they keep track of how they relate to what's in the
persistent store. The main differences to the ideas of jpa are that I
don't support disconnection and you have to do the enhancement
yourself. In a non-locking not-transactional environment I'm not sure
exactly what disconnection means so this might not really be
accurate. IIRC this stuff is all in the sandbox/triplesec-jacc2 branch.
In the past I've tried to describe the kinds of ldap <> object
mappings I need and support in my framework but haven't understood
from Ole whether the DAS will offer similar capabilities.
thanks
david jencks
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
<http://bsd.cs.cofc.edu/Java/Javadocs1.5/api/javax/naming/directory/DirContext.html#modifyAttributes%28javax.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
