geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manu George <manu.t.geo...@gmail.com>
Subject Re: Regd OpenEJB
Date Wed, 11 Jan 2006 10:44:02 GMT
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 ,
> >           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=ind0203&L=ejb-interest&F=&S=&P=22402
> > <
> http://archives.java.sun.com/cgi-bin/wa?A2=ind0203&L=ejb-interest&F=&S=&P=22402
> >.
> > 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* <gianny.damour@optusnet.com.au
> > <mailto:gianny.damour@optusnet.com.au>> 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
> >     >
> >     >
> >     >
> >
> >
> >
>
>
>

Mime
View raw message