Sorry if I'm just jumping on the discussion, but I'd like to understand it a
little more. Is the idea here to have client performing LDAP operations,
using a SDO/DAS layer that can be easily switched back and forth between a
pure LDAP repository and a RDB repository ?

                                             ---> LDAP Respository
Client -> LDAP -> SDO/DAS ->
                                             ---> RDB Repository


Or it's going to be two ways to access the repository, the current way using
LDAP, and also a new way using SDO/DAS ?

--
Luciano Resende
http://people.apache.org/~lresende

On 3/21/07, Ole Ersoy <[EMAIL PROTECTED]> wrote:

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>


Reply via email to