Ole, Comments inside your mail...
On 3/21/07, Ole Ersoy <[EMAIL PROTECTED]> wrote:
<snip/>
SCENARIO-UPDATE
<snip/> 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.
This is something we might consider. Right now, we don't do that because it does not make a lot of sense. Again, an entry is generaly small, so grabing one attribute or the whole entry makes no difference compared to the IO cost (reading some object from disk will be thousand time slower than doing any in-memory manipulation). If we have bigger objects, with bigger values (JPegPhoto for instance), then, yes, we have to do something. But we are already thinking about serializing such objects in streams which will be separated from the entries. (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.)
We should avoid reflection as much as possible. Even in Java 1.5 it's damn costly. We have our own serialization of objects, and we are using it. Now, we want to extend this mechanism to all the attributeTypes, because the gain is enormous (I have been able to speedup the server by 50% just using the serializer for Attributes) If we switch to another internal structuration for objects (have a look at http://cwiki.apache.org/confluence/display/DIRxSRVx11/Backend), then using some other mechanism may be interesting. 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.
In fact, in Ldap, this is exactly what we have : you can't create an object if the schema does not contain the attributeTypes and ObjectClasses. The new system, available in 1.5.0, allow you to define a new ObjectClass, or AttributeType, store it into ADS itself, and then create instances of thise newly created ObjectClass 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.
Don't understand what you mean. Does that make sense?
We are now using ADS as an RDB essentially.
ADS is really close to a RDB. It has a master table storing all the entries, and many BTrees indexing all the needed attributes. More like an Object Oriented Database actually. Hierarchical databes is much closer to the reality. -- Cordialement, Emmanuel Lécharny www.iktek.com
