On 3/21/07, David Jencks <[EMAIL PROTECTED]> 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
