directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: [LDAP DAS] Efficient Updating of Persisted Objects
Date Wed, 21 Mar 2007 14:10:56 GMT
On 3/21/07, David Jencks <david_jencks@yahoo.com> wrote:
>
>
>
> > 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.


In a ldap server, changed informations are done through ModificationItem
elements. A ModificationItem (
http://java.sun.com/products/jndi/1.2/javadoc/javax/naming/directory/ModificationItem.html)
element contains the operation (add, remove, change) and the attribute to be
modifed. If it's an add or remove, this is obvious ( with some special case
like non existing attribute for remove op, or existing attribute for add
op). If it's a modify, then it's a little bit complex because we should take
care of many cases, like non-existing attributes or values, doing an union
of values, etc... Internal affairs ...

This is handled more or less correctly in the server, but what we do is to
upload the entire entry being modified, not each attribute of this entry one
by one, because the entry is serialized as a single object.

The reason is that an entry could have dozens of attributes, and grabbing
all of them could cost much more than reading a single big object. (of
course, as I stated in my previous mail, it depends on the object size : why
would we read a 1Mb JpegPhoto if it has not been modified ?)

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


Bind operation just do one thing : authenticate a user, create a session for
him, and store this session. Authentication is just a lookup in the base to
check that the user credentials are correct. No object are written to the
backend during this operation. And no updating occurs, too.

>
> > Initially I  was thinking that the object's attributes (primitive
> > properties - not references to other objects)
> > would be serialized and made into directory attributes.


There are two cases :
1) the attribute is indexed : we stroe a normalized form of the value(s)
into a specific file.
2)  general case (including indexed attributes) : we store *all* the entry
into a big file, called Mastertable.

Nothing else right now.

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 :-)


The schema is like metaData in a RDBMS : it's always present, and we don't
have to link an attribute to it : the AttributeType is a key to get all the
needed informations from the schema, which is always loaded in memory when
the server is started.

For instance, "uid = jsmith" is an Attribute with a value, which is case
sensitive. The "uid" attributeType is known by the schema, and it has an OID
and also an alias : "uid" <=> "userid" <=> 0.9.2342.19200300.100.1.1. It's
enough to have this key to get all what we need to know from the schema, we
don't have to store any other piece of information within the instance.

Hope it helps.

-- 
Cordialement,
Emmanuel L├ęcharny
www.iktek.com

Mime
View raw message