directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luciano Resende" <luckbr1...@gmail.com>
Subject Re: [DAS to LDAP Type Mapping] Am I thinking about this right?
Date Wed, 04 Apr 2007 00:30:55 GMT
Comments inline...

On 4/3/07, Ole Ersoy <ole.ersoy@gmail.com> wrote:
>
> Hey Luciano,
>
> Excellent question, I'm somewhat new to
> LDAP myself, but luckily the gang here is
> amazingly helpful.  Emmanuel usually answers
> before I've had time to press the send button
> (I think he has ESPN or something....)
> and then everyone else jumps in with lots of helpful
> info right after.
>
>
> Here Goes:
> We're trying to minimize mapping
> tasks.
>
> There are two ways to do this, which I think you
> hinted at in your question.
>
> One is to serialize the DataObject directly
> to the LDAP repository (Storing a Java Object in the repository),
> but then we loose out on the query capabilities that LDAP offers
> us, because the whole object is just a binary blob, and we
> would miss the opportunity to make use of the DataGraph's
> change summary.


So, I'd think you still want to be able to perform search, right ?
Also, regarding DataGraphs (let's assume a collection of person objects from
LDAP) and ChangeSummaries ( what has changed on this collection of person
objects)... I'm not sure if you want to persist things on that level to the
repository, otherwise you might start getting duplications (two dataGraphs
with same person object) and invalid data (like change summaries where
nothing really changed after the read operation), no ? Let's consider the
following scenario : perform a LDAP query, to retrieve members of department
X. This will give you a SDO dataGraph, then the application consuming this
dataGraph manipulates and make data updates that will create changeSummary,
then when you want to applyChanges back to repository, you see what has
changed and only update those entries (an possible just the attributes
changed on specific entries) ... Is this aligned with what you were thinking
?


Initially I was thinking the blob way would be good,
> just to get going, but I would still break up the
> DataGraph into one blob per DataObject.  It turned out
> that doing in the LDAP way is much more attractive, and
> will most likely perform better (Since we can use the DataGraph).
>
> The LDAP Way:
> The other way is to map the simple properties
> of the DataObject to preexisting ObjectClasses.


Yes, I think this is more towards what I was thinking...


The keyword is "Preexisting".  If we are starting
> with a brand new model that has never been written
> to the repository, then we need to write the
> ObjectClasses that correspond to the model's EClass (In Ecore)
> or Type (In the SDO specification) to the repository.
>
> LDAP has the equivalent of Ecore effectively for defining
> metadata.
>
> The LDAP Syntax corresonds to the name member of DataType.
> The LDAP AttributeType corresponds to a DataType.
> The LDAP ObjectClass corresponds to an EClass or Type (SDO)
>
> So the DAS first writes the metadata (Syntaxes, AttributeTypes, and
> ObjectClasses ) to the repository, and then stores each
> DataObject instances using this newly defined LDAP metadata.
>
> If we want to map to existing ObjectClasses, then we need
> a configuration file, just as with the RDB DAS.
>
> Does that help?
>
> Cheers,
> - Ole
>
> P.S. By pure LDAP API, I think you mean JNDI, and yes
> JNDI can now be used to query the DataObjects stored
> in the LDAP repository, just like
> it's used to query the types of
> information that is usually
> stored in the LDAP repository.


:) I think so...

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

Mime
View raw message