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
|