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.
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.
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.
All these points together tend to confuse me on what the actual behaviour should be. Any suggestions?
Thanks
Manu
On 1/7/06, Gianny Damour <[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
>
>
>
