Emmanuel,
I in-more comments, but am adding a little more context first (It's a
bit long though :-) ):
The DAS will do CRUD operations for us.
CREATE
READ
UPDATE
DELETE
So if we were to look at this from an Application point of view
we can imagine the following scenario:
SCENARIO-CREATE:
There is nothing in ADS.
Our application creates an empty SDO model instance, an address for example.
Then it stores the address under
DN: |uid=address,ou=users,ou=system|
So now we can fetch that address instance from there.
SCENARIO-READ
We want the address object so we grab it.
SCENARIO-UPDATE
This is the interesting part.
We we are storing the Address object
as a whole, we can update say only
its street attribute, and then overwrite
the entire persisted object again.
But in reality we really only wish to overwrite
the street attribute of the java object.
Suppose there was an ObjectClass
defined in ADS called
Address.
Then when we did the read operation instead of
deserializing/unmarshaling the object,
we would grab the list of attributes on the entry, pass them to the DAS,
and the DAS would instantiate
the corresponding object for us.
(The DAS would then use the setters on the object
to set those attributes per a predefined map, using
annotations on the object or an xml configuration file.)
So now when we update street, we would only send that updated
attribute back to ADS.
This leads me to the next scenario which is outside of CRUD:
SCENARIO-CREATE-SCHEMA:
This is similar to the creation of a RDB Schema or XML Schema,
but instead of creating these, it's a LDAP Schema defining
new ObjectClasses that correspond to the objects we are persisting.
These would be written to ADS so that attributes of the objects
could be stored the same way we store instances of ObjectClasses
at some DN location.
Does that make sense?
We are now using ADS as an RDB essentially.
More like an Object Oriented Database actually.
Emmanuel Lecharny wrote:
Interesting point. the problem is that when you modify an entry, you
do it by grabbing the entire entry from the disk (or from the cache,
but this is the same problem if the entry is not cached).
Yes - So if objects were broken down into individual attributes we could
let the DAS reconstitute the object from the attributes.
Then when the update is written, the DAS would only need to send the
updated attributes.
Changing an object is done through a ModRequest operation, in which
you give the list of modified attributes. If the entry is not too big
(I mean, no JpegPhoto in it), then it's likely to be less than 1kbytes
to read from the disk. Reading 500 bytes compared to read 1kbytes
makes no difference, as the underlying system will read some 4Kbytes
block (let's assume it's 4Kbytes, even if it's not the real size in
your system). At this point, oprtimizing the server to read only the
modified attributes will not bring enormous gain, if any, but for sure
will add some complexity.
However, if we switch to another backend (ie RDBMS), this might be
something to consider, as we may have to read attributes spreaded all
over a big table. I don't know exactly what would be the pros and cons
right now, but as teh RDBMS backend is not written (and we are still
considering implementing it), this is perfect timing to push new ideas.
Emmanuel
So this is silly - but just for example:
Imagine imagine a Terabyte of addresses stored in ADS.
We wanted to process all the zips to add the new 4 digit extension at
the end,
so mine would go from
60004
to
60004-4232
So I only really wish to update the zip attribute of Address SDO object,
and the SDO change summary has the capability to enable this, but
if we store the entire object on ADS, then we have to write the entire
thing back,
instead of just the changed zip.
So if we were writing to a database, we would just update the zip field
of the database table.
This is also possible with ADS, but we need to generate and store the
ObjectClass for the
address (or could be FooBoo Class, just some random class that we wish
to store).
Thoughts?
Thanks,
- 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 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.
This might lead to performance improvments, if doable...?
Thoughts?
Thanks,
- Ole
--
Cordialement,
Emmanuel Lécharny
www.iktek.com <http://www.iktek.com>
