Shoot - Goota run - I'm off to Canada for a week for a wedding - So I'll
reply more when I get back...
Ciao,
- Ole
Luciano Resende wrote:
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 <http://people.apache.org/%7Elresende>
On 3/21/07, *Ole Ersoy* <[EMAIL PROTECTED]
<mailto:[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]>
> <mailto:[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> <http://www.iktek.com>
