OK - I just answered the one Emmanuel answered before this, anyways...
I think we are all thinking the same thing...
Stefan Seelmann wrote:
Ole,
Ole Ersoy schrieb:
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.
Is that also the case when storing entire javaObjects
in a javaSerializedData attribute?
|I just want to make sure we are clearly separating java object
attributes (Primitive java class members)
from LDAP attributes.
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.
What kind of storage are you thinking of? Saving the entire SDO in the
javaSerializedData or saving the attributes of the SDO?
When storing entire java objects using the javaSerializedData attribute
the whole serialized object is transmitted over the wire and stored as
binary (BLOB). This is a generic way to save any type of serializable
object into a directory. But only Java programs could read this object
from directory again, other programming languages could not handle these
objects. Sun's JNDI LDAP provider uses the javaObject object class and
the javaSerializedData, see RFC2713.
To allow interoperability with other languages is would be better to
save objects as entries with attributes, maybe using a custom schema
with special object classes and attribute types. Then of course a
mapping between the java classes and attributes and the LDAP object
classes and attribute types is needed.
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?
Yes.
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?
Then update userName. Then serialize userClass back to ADS again?
|
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. I'll
hold off on commenting more in case I'm getting warmer.
Yeah, I think that would be the better approach.
I also think that the LDAP DAS isn't limited to ApacheDS as backend. Any
LDAP directory could be used as backend.
Regards,
Stefan
