directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: [LDAP DAS] Efficient Updating of Persisted Objects
Date Wed, 21 Mar 2007 21:19:39 GMT
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* <ole.ersoy@gmail.com 
> <mailto:ole.ersoy@gmail.com>> 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* <ole.ersoy@gmail.com
>     <mailto:ole.ersoy@gmail.com>
>     > <mailto:ole.ersoy@gmail.com <mailto:ole.ersoy@gmail.com>>> 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>
>
>
>
>


Mime
View raw message