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* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
>
>
>
