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* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
