OK - Cool - So for LDAP DAS version 1.0
I'll just write the entire SDO datagraph to ADS with each
SDO object being an entry.
Also, (Just wanted to make sure I understand) are you saying that
having a RDB backend because of:
High volumes
Reliability
Replications
Marketing
Makes sense?
Emmanuel Lecharny wrote:
On 3/21/07, *Ole Ersoy* <[EMAIL PROTECTED]
<mailto:[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 <http://www.iktek.com>
