On 3/21/07, Ole Ersoy <[EMAIL PROTECTED]> wrote:
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.
In fact, we pass attributes and we update them in a whole object before storing it. To be able to do that, we first have to get the whole object out of the backend. For instance, if you want to add a userPassord to the uid=oersoy, dc=apache, dc=com entry, you will just pass a modifyRequest with the DN, and the userPassord attribute with the value to add. Then the server will search for the corresponding entry from its DN, and if found, it will read it entirely. Then it will add the attribute into the entry, and save it into the backend. 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.
Well, the criteria must still be implemented ... It's now 2 years we know we have to deal with such a criteria, but we didn't had time to implement it yes... 1.5.2 maybe 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.
We can say that Since this is the case, then the DAS implementation will be really
straight forward I think.
Well, it's pretty much done in two classes only, AttributesSerializerUtils and AttributeSerializerUtils. Only 700 lines of code, javadoc included :) 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.
yep.
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?
There are many, including high volumes, reliability, replications, marketing, "We already have Or*cle/I*m db*/MySql/PostGresql" (TM), ... I mention this because Tuscany also has a DAS for RDB. We have had discussion with Tuscany guys in Austin about including ADS into tuscany. So an SDO model could serve as a middle tier between RDB persistance and
LDAP persistance.
That may be a very good idea, because then it may abstract totally the plumbery between ADS and the backend. At the moment, this plubery is not really satisfactory. 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...
Yep. Anyways, should probably put that in a different thread or JIRA or
something...or the ADS design document that I need to get started...
We are seriously thinking about it for a 2.0 version of ADS. We might discuss this in may, during ApacheCon (if the number of beers we will absorb, not to mention the strange substances we will smoke, keep our brain productive :) -- Cordialement, Emmanuel Lécharny www.iktek.com
