Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (herse.apache.org: domain of ole.ersoy@gmail.com designates
 64.233.162.237 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=apICrTiT5gn7PlRKvGsN6/oZUu2mB5PE9zl781zcx/dbYizj0+JmAC4XVBgT+4Fw5B+v/RDnds2/M37/mm0O+iiV9+9T1xVc3uvKn0i5ptc1mTGDXtQry2g4GI2hANKWSGLapAidUTynQaihK9Xy+ifgJEdEE2fXquIIe5iIjVU=
Message-ID: <460B1FE4.4070708@gmail.com>
Date: Wed, 28 Mar 2007 21:09:40 -0500
From: Ole Ersoy <ole.ersoy@gmail.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070302)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [LDAP DAS] Efficient Updating of Persisted Objects
References: <4600BD43.3090406@gmail.com>
	 <a32f6b020703270828g71db3851kbbf6d51d621d2040@mail.gmail.com>
	 <4609F725.60307@gmail.com>
 <a32f6b020703281758r6ca0e5eldc753fd652db5b5d@mail.gmail.com>
In-Reply-To: <a32f6b020703281758r6ca0e5eldc753fd652db5b5d@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

OK - I just sent another reply - that sort of makes this on irrelevant, 
but I'll send it anyways for context....

Alex Karasulu wrote:
> Hi Ole,
>  
> Excuse the late response ... I've been lazy while on vacation.  More 
> inline ...

Yeah - The Balls - Vacationing and Sheeeet :-)

Welcome back!
>  
> On 3/28/07, *Ole Ersoy* <ole.ersoy@gmail.com 
> <mailto:ole.ersoy@gmail.com>> wrote:
>
>     Alex Karasulu wrote:
>     > Ole,
>     >
>
>  
> SNIP ...
>
>     > Hmmm with heirarchical services in JNDI you should not be using
>     > bind().  You
>     > should be using the createSubcontext() and modifyAttributes()
>     methods
>     > instead.
>
>
>     Oh OK.  My impression was that I would use createSubcontext() when
>     creating a new context for a serialized java object for example.
>
>  
>  
> Oh sorry I thought you were not storing a serialized object.  Then 
> bind() would
> help you accomplish that I think.  However this is not very efficient 
> because
> of the reasons you mention: you would in essence be updating the 
> entire object
> when just one member changes.  And you're dealing with a blob of 
> serialized
> data which is bigger.  Meaning the transfers are bigger for a small 
> change in the
> overall object.

Yeah I was actually going to break the the object graph up
so that the entire DataGraph would not get stored in one entry,
but instead I would store proxies that only had the non object
references stored, and then a proxy would be used to load the reference,
but even this is somewhat non-sexy.

>  
>  
> My impression was that you were converting an object into an entry 
> with attributes
> for it's properties which is more like what you do when you persist an 
> object in a
> record in a database.  For example you have a User object and you 
> convert that
> into a set of attributes like so:

Yes - That is what I want to do.

So first I want to create an ObjectClass that has a 1:1 relationship 
with a java class.

This is somewhat similar to creating doing a CREATE TABLE TABLE_NAME in SQL,
but different when there is only a single instance of the class's type 
in the model.
>  
> givenName: johny
> surName: walker
> commonName: wiskey
> age: 12
>  
> etc ...
>  
> Then this way you would call createSubcontext with the attributes and 
> that would
> persist the entry.

Yes - And then I would assign the custom ObjectClass to this entry.

> If you change the age to 15 then there is a single update operation
> on that attribute. 

It's a beautiful thing!

> Also this way indexing can be taken advantage of for attributes for
> speeding up search.  I have no idea how you would search for 
> serialized objects in
> a directory efficiently.

Fabulous!
>
>     Let me give an exampel - I'll be starting the DAS "serious" work
>     tomorrow,
>     so if I'm off on this, I'll eventually find out :-), but this may
>     help
>     facilitate
>     the conversation with respect to updating attributes vs. the
>     entire object.
>
>     Suppose my initial context is:
>
>     |uid=ole,ou=users, ou=system
>     |
>
>     And I wanted to add a sub context for an Instance of MyClass
>     with reference named myClassInstance
>
>     I could do something like
>
>     ctx.createSubcontext("cn=myClassInstance");
>
>     Which would create the context:
>
>     |cn=myClassInstance, uid=ole, ou=users, ou=system| 
>
>  
> I think you were right in using bind() where you provide the object to 
> serialize.  This createSubcontext() operation will merely create a 
> javaContainer I think.  There's an
> RFC on this which I implemented a while back and you can find more 
> info in the
> JNDI tutorial about this as well.
>  
> However again I don't think using this serialization mechanism is such 
> a good idea
> because of the search implications.  How would you search a blob of 
> binary data
> effectively?

Indeed.

>
>     Then to store a my serialized myClassInstance under this dn in a
>     javaSerializedData attribute, I would do something like this:
>
>     |||String bindContext = "cn=|myClassInstance|,uid=ole,ou=users,
>     ou="system";|
>
>     |ctx.bind( bindContext, ||nameOfMyObject||)
>
>
>     I'm also guessing that the bind operation would take care
>     of the createSubcontext() step for me, ... but anyways...
>
>  
> Yes you were right.  Actually you would not need to createSubcontext() 
> operation at all just use bind(). 
>  
> I recommend just going through the JNDI tutorial on this stuff and 
> testing these operations on the server just to see what happens.
>
>     |
>
>     > You
>     > might want to go through the JNDI tutorial for LDAP just to get
>     a good
>     > feel for how to
>     > work with non-flat namespaces using JNDI.  Namely with LDAP you
>     don't
>     > need to
>     > rebind the object with a modification to an attribute.  This is what
>     > the modify
>     > operations are for.
>
>     Just want to make sure we are talking about the same thing here.
>     We may have some attributes stored in ADS under:
>     |DN: uid=ole,ou=users, ou="system
>
>     This DN has the Person ObjectClass associated with it.
>     So I may wish to change one of the attributes (The password attribute
>     for instance)
>     that are associated with the Person ObjectClass.
>     Then I could see using a modify operation.
>
>  
> Yeah we're mixing object serialization here with converting that 
> object to an entry with attributes.
>
>     Is that also the case when storing entire javaObjects
>     in a javaSerializedData attribute?
>
>  
> Technically you can use modify on javaSerializedData but you're 
> replacing the blob of serialized bytes representing the serialized 
> object. 
>  
>
>     |I just want to make sure we are clearly separating java object
>     attributes (Primitive java class members)
>     from LDAP attributes.
>
>  
> Basically my advice would be to stay clear of using java serialization 
> in the directory.
>
Diddo
>
>     Let me stop here in case I'm making any sense?
>
>     If not hopefully once I'm done writing the design guide and get a
>     terminology and concept section going
>     things will be a little clearer.
>
>
>     >
>     http://bsd.cs.cofc.edu/Java/Javadocs1.5/api/javax/naming/directory/DirContext.html#modifyAttributes(javax.naming.Name
>     <http://bsd.cs.cofc.edu/Java/Javadocs1.5/api/javax/naming/directory/DirContext.html#modifyAttributes%28javax.naming.Name>
>     > <
>     http://bsd.cs.cofc.edu/Java/Javadocs1.5/api/javax/naming/directory/DirContext.html#modifyAttributes%28javax.naming.Name>,
>     > int, javax.naming.directory.Attributes)
>     >
>     >
>     Cool - I'll have a looksee - I've been using the articles on the
>     ApacheDS website as a reference so far, but the more material the
>     better.
>
>     >
>     >
>     >     Initially I  was thinking that the object's attributes
>     (primitive
>     >     properties - not references to other objects)
>     >     would be serialized and made into directory attributes.  But
>     I think a
>     >     LDAP ObjectClass schema that corresponds to the
>     >     object's class (The class of the object we are persisting)
>     would
>     >     have to
>     >     be generated and stored along with the instance.
>     >
>     >     This might lead to performance improvments, if doable...?
>     >
>     >     Thoughts?
>     >
>     >
>     > Hmmm I think some of your premisses in this question may be due to
>     > considering the use
>     > of bind() instead of using modifyAttributes() and
>     createSubcontext().
>     > If you use these methods
>     > I think there is no further preformance issue to consider.  WDYT?
>
>     Ahh - This is the part where I need clarification.
>
>     If we serialize an entire object to ApacheDS, then we have to get it
>     from ApacheDS,
>     update it, and send it back to be stored in a javaSerializedData
>     attribute right? 
>
>  
> Right exactly!  This is why java LDAP serialization is not a good idea 
> for your DAS thingy.
>
>     For instance I may have a Class called UserClass with a String member
>     userName.
>
>     I create an instance of UserClass called userClass.
>
>     The I do
>     userClass.setUserName("ole");
>
>     Now I want to store userClass in ADS here:
>     |DN: cn=|userClass|,ou=users, ou="system
>
>     So I do this:
>
>     ||String bindContext = "cn=|myClassInstance|,ou=users, ou="system";|
>
>     |ctx.bind( bindContext, ||userClass||);
>
>     Now userClass is in ADS stored as a javaSerializedData LDAP
>     attribute value,
>     hanging off of the bindContext I specified.
>
>     Later when I want to update
>     the userName member of the UserClass instance I serialized to ADS,
>     I need to use JNDI to load the instance again right?
>
>  
> Yep unless you write the code to resusitate the serialized object 
> manually.
>
>     Then update userName.  Then serialize userClass back to ADS again?
>
>  
> Yep.
>
>     |
>
>     WDYT?
>
>     I mentioned some stuff about generating an ObjectClass schema that is
>     the LDAP schema of the Java Class UserClass,
>     so that the primitive members (That have java primitive types)
>     would be
>     stored as LDAP atttributes rather than storing the entire
>     object as a single javaSerializedData attribute attached to a DN.  
>
>  
> Yes this would be best in my opinion.

Yeeeeeeeessss!!!!!!!!!

Cool - I think we are all on the same page now.

So my question is:

Can I use my directory context to first
create a new ObjectClass that corresponds to my
Java Class?

OK - I just asked this again in the other mail I just sent, so I'll stop 
here.


>  
> Regards,
> Alex
>
>  
>

Cheers,
- Ole