Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 24262 invoked from network); 11 Jan 2006 10:44:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 11 Jan 2006 10:44:29 -0000 Received: (qmail 27105 invoked by uid 500); 11 Jan 2006 10:44:26 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 26777 invoked by uid 500); 11 Jan 2006 10:44:25 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 26762 invoked by uid 99); 11 Jan 2006 10:44:25 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Jan 2006 02:44:25 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of manu.t.george@gmail.com designates 64.233.184.206 as permitted sender) Received: from [64.233.184.206] (HELO wproxy.gmail.com) (64.233.184.206) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Jan 2006 02:44:24 -0800 Received: by wproxy.gmail.com with SMTP id 58so95946wri for ; Wed, 11 Jan 2006 02:44:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=hugTargaDACZF6TtLE9YGx54hTCGOFPmnHze5b0ilwFavf+jwTzx/byFd8dXncP2xPuB34BeJ2zV6Pe0dkOXMyCFRIEtV+cedUNbjDeuBS1XwrRYOuu0teXVZCV+aDc8jpzyn1uNf/PAX+HTUR/NyNWScYDf4umTEfk0A6ZqF3o= Received: by 10.65.53.1 with SMTP id f1mr168919qbk; Wed, 11 Jan 2006 02:44:02 -0800 (PST) Received: by 10.65.185.10 with HTTP; Wed, 11 Jan 2006 02:44:02 -0800 (PST) Message-ID: <466797bd0601110244u760083dctc8bffc20d6b86b4c@mail.gmail.com> Date: Wed, 11 Jan 2006 16:14:02 +0530 From: Manu George To: dev@geronimo.apache.org Subject: Re: Regd OpenEJB In-Reply-To: <43C3A51F.4020702@optusnet.com.au> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_44061_17190271.1136976242850" References: <466797bd0601050340n1461fb7s750cef54e1356435@mail.gmail.com> <43BF1C64.8020703@optusnet.com.au> <466797bd0601090507y725f3590qdf48cd54677e3c49@mail.gmail.com> <43C3A51F.4020702@optusnet.com.au> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_44061_17190271.1136976242850 Content-Type: multipart/alternative; boundary="----=_Part_44062_13233189.1136976242850" ------=_Part_44062_13233189.1136976242850 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Gianny, Here is the code snippet for supporting the first scenario.But thi= s will not support the second scenario we discussed. Thanks Manu On 1/10/06, Gianny Damour wrote: > > Hi Manu, > > Manu George wrote: > > > Hi , > > I am also not sure if this is a safe behaviour or even > > whether the ejb spec requires it. I have seen in a particular sun > > forum that the pk should not be part of any relation. > > I have put the link below > > > http://archives.java.sun.com/cgi-bin/wa?A2=3Dind0203&L=3Dejb-interest&F= =3D&S=3D&P=3D22402 > > < > http://archives.java.sun.com/cgi-bin/wa?A2=3Dind0203&L=3Dejb-interest&F= =3D&S=3D&P=3D22402 > >. > > If this is true then there is no issue at all with the existing code > > but I am not sure whether this is true as in some containers like > > Websphere this is allowed. I went through the parts of the specs > > mentioned in the posting quickly but it didn't resolve my doubts. > > We need to support the case where a pk column is also a fk column. For > instance, SPECj is using such a mapping and our current implementation > is able to "run" SPECj - we support the scenario where a compound pk > field is mapped to a foreign key column referencing the pk column of a > CMP having a "simple" pk class. > > > > > Another Issue that pops up if we allow to set the foreign key field is > > in the ejbPostCreate if the bean provider tries to set the cmrField > > the container will set the fk automatically and thereby try to change > > the PK which should not be done once an ejb is created. So there also > > we need to add certain checks. > > We are implementing such checks - at least for the case that we support. > They are implemented by CMRMappedToInversePKCMP and > CMRMappedToOwningPKCMP. We have a set of OpenEJB itests, > CMRMappingFacadeBean, which amongst other things verify that we cannot > change the PK of a CMP by setting a CMR field - the four tests > test*ResetPK. > > > > > All these points together tend to confuse me on what the actual > > behaviour should be. Any suggestions? > > The case where we have: > * a composite primary key having three columns (b, fka1, fka2); and > * (fka1, fka2) also foreign key columns referencing the composite > primary key (a1, a2). > seems to be rare. However, it seems that we should be able to support it > via the same mechanism that we used for CMRMappedToInversePKCMP and > CMRMappedToOwningPKCMP. > > I think that the first thing to do is to add support for your very first > scenario. I think that this is more or less that code snippet that you > have submitted a couple of days ago. > > Thanks, > Gianny > > > > > Thanks > > Manu > > > > > > On 1/7/06, *Gianny Damour* > > wrote: > > > > Hi Manu, > > > > You are once again correct: let's remove this read-only decorator > > - this > > was a very bad idea - at least if the field is a PK one. This read > > only > > behavior was intended to prevent developers from changing a > > relationship > > to a CMP having a coumpond PK with multiple fields. Indeed, in this > > case, if the CMP field is updated, this implies that the > > relationship is > > (partially, as only one field is updated) updated and I am not > > sure that > > it is safe to let such a thing to happen. > > > > Thanks for your work on this, > > Gianny > > > > Manu George wrote: > > > > > Hi Gianny, > > > I have a question on CMR > > > Consider a Bean A and a bean B in a one to many CMR > > > relationship > > > Here A has 2 fields in the PK say a1 and a2 > > > B has b1 fka1 and fka2 as the pk where fka1 > and > > > fka2 are the foreign keys corressponding to the a1 and a2 of A. > > > In the ejbCreate of B when we set fka1 and fka2 won't > > > OpenEJB throw an error saying that they are readonly fields. > > This will > > > happen even after implementing the logic for the special case > where > > > the CompoundPK has 1 field. Is this scenario a valid scenario? > > If so > > > can we change the check in createCMPFieldAccessors to check for > > > primary key and allow write access to CMR fields if they are > > parts of > > > Primary Keys? What should be the correct behaviour? > > > > > > Thanks > > > Manu > > > > > > > > > > > > > > > > > > ------=_Part_44062_13233189.1136976242850 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Gianny,
         Here is the code snippet for supporting the first scenario.But this will not support the second scenario we discussed.

Thanks
Manu      

On 1/10/06, Gianny Damour <gianny.damour@optusnet.com.au= > wrote:
Hi Manu,

Manu George wrote:

> Hi ,
>  &nbs= p;        I am also not sure if this is = a safe behaviour or even
> whether the ejb spec requires it. I have s= een in a particular sun
> forum that the pk should not be part of any= relation.
> I have put the link below
> http://archives.java.sun.com/cgi-bin/wa?A2=3Dind0203&L=3Dejb= -interest&F=3D&S=3D&P=3D22402
> <http://archives= .java.sun.com/cgi-bin/wa?A2=3Dind0203&L=3Dejb-interest&F=3D&S= =3D&P=3D22402 >.
> If this is true then there is no issue at all with the existi= ng code
> but I am not sure whether this is true as in some container= s like
> Websphere this is allowed.  I went through the par= ts of the specs
> mentioned in the posting quickly but it didn't resolve my doubts.<= br>
We need to support the case where a pk column is also a fk column. F= or
instance, SPECj is using such a mapping and our current implementatio= n
is able to "run" SPECj - we support the scenario where a comp= ound pk
field is mapped to a foreign key column referencing the pk colum= n of a
CMP having a "simple" pk class.

>
> Ano= ther Issue that pops up if we allow to set the foreign key field is
> in the ejbPostCreate if the bean provider tries to set the cmrFiel= d
> the container will set the fk automatically and thereby try to ch= ange
> the PK which should not be done once an ejb is created. &= nbsp;So there also
> we need to add certain checks.

We are implementing such che= cks - at least for the case that we support.
They are implemented by CMR= MappedToInversePKCMP and
CMRMappedToOwningPKCMP. We have a set of OpenEJ= B itests,
CMRMappingFacadeBean, which amongst other things verify that we cannot<= br>change the PK of a CMP by setting a CMR field - the four tests test*Rese= tPK.

>
> All these points together tend to confuse me on wh= at the actual
> behaviour should be. Any suggestions?

The case where we hav= e:
* a composite primary key having three columns (b, fka1, fka2); and* (fka1, fka2) also foreign key columns referencing the composite
primary key (a1, a2).
seems to be rare. However, it seems that we should= be able to support it
via the same mechanism that we used for CMRMapped= ToInversePKCMP and
CMRMappedToOwningPKCMP.

I think that the first= thing to do is to add support for your very first
scenario. I think that this is more or less that code snippet that you<= br>have submitted a couple of days ago.

Thanks,
Gianny

>= ;
> Thanks
> Manu
>
>
> On 1/7/06, *Gianny Da= mour* < gianny.damour@optusnet.com= .au
> <mailto:gianny.damour@optusnet.com.au>> wrote:
>
> &nbs= p;   Hi Manu,
>
>     You are once again correct: let's = remove this read-only decorator
>     - this
&= gt;     was a very bad idea - at least if the field is = a PK one. This read
>     only
>  = ;   behavior was intended to prevent developers from changing a
>     relationship
>   &nbs= p; to a CMP having a coumpond PK with multiple fields. Indeed, in this
&= gt;     case, if the CMP field is updated, this implies= that the
>     relationship is
> &nbs= p;   (partially, as only one field is updated) updated and I am n= ot
>     sure that
>     = it is safe to let such a thing to happen.
>
>   =   Thanks for your work on this,
>     Gianny=
>
>     Manu George wrote:
>
>=      > Hi Gianny,
>     >            = ; I have a question on CMR
>     >            = ;Consider a Bean A and a bean B in a one to many CMR
>     = > relationship
>     >            = ; Here A has 2 fields in the PK say a1 and a2
>     >            = ;         B has b1 fka1 and fka2 as the pk where fka1 and
>   &n= bsp; > fka2 are the foreign keys corressponding to the a1 and a2 of A.>     >            = ; In the ejbCreate of B when we set fka1 and fka2 won't
>  &n= bsp;  > OpenEJB throw an error saying that they are readonly fields= .
>     This will
>    = > happen even after  implementing the logic for the special c= ase where
>     > the CompoundPK has 1 field. &nbs= p;Is this scenario a valid scenario?
>     If so<= br>>     > can we change the check in createCMPFi= eldAccessors to check for
>     > primary key = and allow write access to CMR fields if they are
>     parts of
>     &= gt; Primary Keys? What should be the correct behaviour?
>  =    >
>     > Thanks
> =     > Manu
>     >
>&n= bsp;    >
>     >
>>
>



------=_Part_44062_13233189.1136976242850-- ------=_Part_44061_17190271.1136976242850 Content-Type: application/octet-stream; name=CMPContainerBuilder.patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="CMPContainerBuilder.patch" Index: CMPContainerBuilder.java =================================================================== RCS file: /home/projects/openejb/scm/openejb/modules/openejb-builder/src/java/org/openejb/deployment/CMPContainerBuilder.java,v retrieving revision 1.33 diff -r1.33 CMPContainerBuilder.java 116a117 > import org.tranql.ejb.CMRCompoundAccessor; 368c369 < if (relatedEJB.isCompoundPK()) { --- > if (relatedEJB.isCompoundPK() && relatedEJB.getPrimaryKeyFields().size() > 1) { 384a386,389 > } else if(relatedEJB.isCompoundPK()) { > IdentityDefiner identityDefiner = identityDefinerBuilder.getIdentityDefiner(end.getEntity()); > IdentityTransform transform = identityDefinerBuilder.getPrimaryKeyTransform(relatedEJB); > accessor = new CMRCompoundAccessor(cmrAccessor, accessor, transform, identityDefiner, relatedEJB.getPrimaryKeyClass(), i); ------=_Part_44061_17190271.1136976242850 Content-Type: application/octet-stream; name=CMRCompoundAccessor.java Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="CMRCompoundAccessor.java" /** * * * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package org.tranql.ejb; import java.lang.reflect.Field; import javax.ejb.EJBException; import org.tranql.cache.CacheRow; import org.tranql.cache.InTxCache; import org.tranql.field.NestedRowAccessor; import org.tranql.field.Row; import org.tranql.identity.GlobalIdentity; import org.tranql.identity.IdentityDefiner; import org.tranql.identity.IdentityTransform; import org.tranql.identity.IdentityTransformException; /** * Accessor Class for accessing an FK field that maps to the PK of another * class. This PK a CompoundPK with a single field. * */ public class CMRCompoundAccessor implements CMPFieldTransform { private final CMPFieldTransform cmrField; private final CMPFieldTransform cmpField; private final IdentityTransform transform; private final IdentityDefiner identityDefiner; private final Class pkClass; private int slot; public CMRCompoundAccessor(CMPFieldTransform cmrField, CMPFieldTransform cmpField, IdentityTransform transform, IdentityDefiner identityDefiner, Class pkClass,int slot) { this.cmrField = cmrField; this.cmpField = cmpField; this.transform = transform; this.identityDefiner = identityDefiner; this.pkClass = pkClass; this.slot = slot; } public Object get(InTxCache cache, CacheRow cacheRow) { GlobalIdentity id = (GlobalIdentity) cmrField.get(cache, cacheRow); Row row = identityDefiner.extractIdentity(id); CMPFieldNestedRowAccessor accessor = new CMPFieldNestedRowAccessor(cmpField, slot); return accessor.get(cache,cacheRow); } public void set(InTxCache cache, CacheRow row, Object value) { GlobalIdentity id; Object pkObject; try { pkObject = pkClass.newInstance(); Field[] fields = pkClass.getFields(); fields[0].set(pkObject, value); } catch (IllegalArgumentException e) { throw new EJBException("Cannot extract global identity", e); } catch (IllegalAccessException e) { throw new EJBException("Cannot extract global identity", e); } catch (InstantiationException e) { throw new EJBException("Cannot extract global identity", e); } try { id = transform.getGlobalIdentity(pkObject); } catch (IdentityTransformException e) { throw new EJBException("Cannot extract global identity", e); } cmpField.set(cache, row, value); cmrField.set(cache, row, id); } } ------=_Part_44061_17190271.1136976242850--