On Mar 21, 2007, at 1:06 AM, 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.
Maybe you documented this somewhere I missed, but could we back up a
little bit and see if we agree or understand what the goals are?
For this to be useful to me in triplesec it needs to be able to do
what the framework I wrote does:
- map single valued attributes in an entry to an object field
- map single and multiple valued attributes to an object reference or
collection/map of object references respectively
- map multiple valued attributes to collection valued fields of
simple types
- map the natural ldap tree structure to object tree structure
- leave out layers of the ldap tree that convey type information
rather than instance data (such as "ou=Application")
those are the important ones I can remember... I hope I didn't leave
anything too critical out.
Also I don't know much of anything about SDO.... do you write your
own POJOs and then map/enhance/code generate/?? to relate them to the
backend data store or are classes generated from a description of the
data store or are there generic data structures like a map of
attribute name to attribute value?
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.
Tracking change information is usually desirable whether or not you
support disconnection.
This makes it possible to only update objects that have been
changed, and
we only need to update the fields that were changed.
However, I think the DirContext will overwrite the entire
object during the bind operation, rather than updating specific
fields on the object.
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.
I don't know what you mean by this. Could you provide a simple
concrete example? Probably my lack of knowledge about ldap :-)
thanks
david jencks
This might lead to performance improvments, if doable...?
Thoughts?
Thanks,
- Ole
