Emmanuel,
I think my squirrel brain is starting to put together what you are
saying :-)
Let me see if I'm getting it.
ATTRIBUTES VS. ENTIRE OBJECT
Whether we pass an entire object or an individual attribute to ADS when
updating,
performance wise there's probably no difference since it's such a small
chunk of info.
This applies at when ADS serialized to disk and when the Application
sends data to ADS
via the directory context per the criteria that object's size is below a
certain number of KB.
So from a "Passing the Baton" point of view, it does not matter whether
it is a attribute or
an object...since their size different is typically so small.
Since this is the case, then the DAS implementation will be really
straight forward I think.
I'll just skip commenting on the rest of your in lined comments, if I
understand correctly,
since the rest is not really important anyways.
JUST A SIDE NOTE:
RDB Backend for ApacheDS
If we did this, then passing an attribute instead of an Object might
make sense, if I understand correctly.
From what I understand rear ends like Prevayler
are thousands of times faster than any RDB, even if the entire RDB were
stored in main memory (Like with hsql),
so would there ever be a point in using an RDB?
I mention this because Tuscany also has a DAS for RDB.
So an SDO model could serve as a middle tier between RDB persistance and
LDAP persistance.
Applications that need an RDB rear end, could pull info out of ADS using
the
DAS for LDAP, and store in in any RDB using DAS for RDB...
Anyways, should probably put that in a different thread or JIRA or
something...or the ADS
design document that I need to get started...
- Ole
Emmanuel Lecharny wrote:
Ole,
Comments inside your mail...
On 3/21/07, *Ole Ersoy* <[EMAIL PROTECTED]
<mailto:[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 <http://www.iktek.com>
