directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole.er...@gmail.com>
Subject Re: [LDAP DAS] Efficient Updating of Persisted Objects
Date Wed, 28 Mar 2007 20:51:40 GMT
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
>
>   


Mime
View raw message