Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 58125 invoked from network); 27 Mar 2007 16:57:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Mar 2007 16:57:16 -0000 Received: (qmail 78026 invoked by uid 500); 27 Mar 2007 16:57:23 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 77996 invoked by uid 500); 27 Mar 2007 16:57:23 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 77985 invoked by uid 99); 27 Mar 2007 16:57:23 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Mar 2007 09:57:23 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [68.142.206.241] (HELO smtp108.plus.mail.mud.yahoo.com) (68.142.206.241) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 27 Mar 2007 09:57:12 -0700 Received: (qmail 82456 invoked from network); 27 Mar 2007 16:56:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:From:Subject:Date:To:X-Mailer; b=SV83EisjYEq6YR46EhwpmRsJoBo32H63mS6u5IjG/zZcuMIYIE9D82gOtwJUDxPgCIgAHg+eet1D/aEPFD+p4vevCdbPHoDD1afc449EnTY5y3ei4c2aBTOnCGmSE6PitSmyER0mlIesuHtlLuIG0uYZuQIPb/4lGIUBHqMFLVk= ; Received: from unknown (HELO ?192.168.1.101?) (david_jencks@74.237.109.96 with plain) by smtp108.plus.mail.mud.yahoo.com with SMTP; 27 Mar 2007 16:56:50 -0000 X-YMail-OSG: QwIMetIVM1lWDvUPGemqmT1_Gk_hosTrGhEJ9u9DIS1XUQDmGtkclM2h0SYz5pHj69dwZF2l_SnKDn7HfR_IGrFnAaWMel79Cku0w0CdMFtRpsk1Sac- Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <4600BD43.3090406@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2--861090680 Message-Id: From: David Jencks Subject: Re: [LDAP DAS] Efficient Updating of Persisted Objects Date: Tue, 27 Mar 2007 12:56:44 -0400 To: "Apache Directory Developers List" X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-2--861090680 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 27, 2007, at 11:28 AM, Alex Karasulu wrote: > Ole, > > On 3/21/07, Ole Ersoy wrote: > Hey Guys, > > Just wanted to see if anyone had any thoughts on handling updates > to Java beans (Service Data Objects - but basically the same thing) > persisted with ADS. > > With Service Data Objects we create a datagraph that is then > disconnected > from it's persistence source and we can mutate it. Then later we > want to > persist the graph. Each object in the graph has a change summary, > that > stores the fields that were updated. > > This change summary is very interesting. I had experimented with > something > similar which David Jencks did not like too much. Basically the > modifier pattern > was being used to track modifications to attributes of entities. > It was tracking > the set of modify add, remove, and replace operations to perform on > each attribute. What I didn't like was that you were keeping track of the modifications outside the POJO-like data object itself in (IMO) very hard to use helper objects, and you didn't write a framework. I took essentially the same idea and came up with something pretty similar to jpa/jdo, where you have things that look like POJOs to the outside world, but inside they keep track of how they relate to what's in the persistent store. The main differences to the ideas of jpa are that I don't support disconnection and you have to do the enhancement yourself. In a non-locking not-transactional environment I'm not sure exactly what disconnection means so this might not really be accurate. IIRC this stuff is all in the sandbox/triplesec-jacc2 branch. In the past I've tried to describe the kinds of ldap <> object mappings I need and support in my framework but haven't understood from Ole whether the DAS will offer similar capabilities. thanks david jencks > > > This makes it possible to only update objects that have been > changed, and > we only need to update the fields that were changed. > > Exactly this is what I was doing in this one admin API I had in > triplesec. > > > However, I think the DirContext will overwrite the entire > object during the bind operation, rather than updating specific fields > on the object. > > Hmmm with heirarchical services in JNDI you should not be using bind > (). You > should be using the createSubcontext() and modifyAttributes() > methods instead. 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. > http://bsd.cs.cofc.edu/Java/Javadocs1.5/api/javax/naming/directory/ > DirContext.html#modifyAttributes(javax.naming.Name , int, > javax.naming.directory.Attributes) > > > > 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? > > Alex > > > --Apple-Mail-2--861090680 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Mar 27, 2007, = at 11:28 AM, Alex Karasulu wrote:

Ole,

=
On 3/21/07, Ole Ersoy <ole.ersoy@gmail.com> = wrote:
Hey Guys,

Just wanted to see if anyone had any = thoughts on handling updates
to Java beans (Service Data Objects - = but basically the same thing)
persisted with ADS.

With = Service Data Objects we create a datagraph that is then = disconnected
from it's persistence source and we can mutate it.=A0=A0Th= en later we want to
persist the graph.=A0=A0Each object in the graph = has a change summary, that
stores the fields that were = updated.
=A0
This change summary is very = interesting.=A0 I had experimented with something
similar = which David Jencks did not like too much.=A0 Basically the modifier = pattern
was being used to track modifications to attributes = of entities.=A0 It was tracking
the set of modify add, = remove, and replace operations to perform on each = attribute.

What I didn't like was that you = were keeping track of the modifications outside the POJO-like data = object itself in (IMO) very hard to use helper objects, and you didn't = write a framework. =A0I took essentially the same idea and came up with = something pretty similar to jpa/jdo, where you have things that look = like POJOs to the outside world, but inside they keep track of how they = relate to what's in the persistent store.=A0 The main differences to the = ideas of jpa are that I don't support disconnection and you have to do = the enhancement yourself.=A0 In a non-locking not-transactional = environment I'm not sure exactly what disconnection means so this might = not really be accurate.=A0 IIRC this stuff is all in the = sandbox/triplesec-jacc2 branch.

In the past I've tried to = describe the kinds of ldap <> object mappings I need and support = in my framework but haven't understood from Ole whether the DAS will = offer similar capabilities.

thanks
david = jencks

=

=A0
This makes it possible to only update objects that have been = changed, and
we only need to update the fields that were changed. =
=A0
Exactly this is what I was doing in = this one admin API I had in triplesec.

=A0
=
However, I think the = DirContext will overwrite the entire
object during the bind = operation, rather than updating specific fields
on the = object.
=A0
Hmmm with heirarchical services = in JNDI you should not be using bind().=A0 You
should be = using the createSubcontext() and modifyAttributes()=A0methods instead.=A0 = 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.=A0 Namely with LDAP you don't need to
rebind the = object with a modification to an attribute.=A0 This is what the modify =
operations are for.

http://bsd.cs.cofc.ed= u/Java/Javadocs1.5/api/javax/naming/directory/DirContext.html#modifyAttrib= utes(javax.naming.Name , int, javax.naming.directory.Attributes)

=

=A0
Initially I=A0=A0was thinking that the object's attributes = (primitive
properties - not references to other objects)
would be = serialized and made into directory attributes.=A0=A0But 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?
=
=A0
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().=A0 If you use these = methods
I think there is no further preformance issue to = consider.=A0 WDYT?
=A0
Alex
=
=A0



= --Apple-Mail-2--861090680--