-
1. Re: Is this a jboss bug (entity setter mehod)?
The database is updated at synchronization time, i.e. at tx commit, before the finder or select method, before remove. Not just before CMR setter invocation.
-
2. Re: Is this a jboss bug (entity setter mehod)?
I am not quite clear of what your saying.
Based on my observation, the outcome is after all the related transactions are commited,the old relationship are still there while new ones are added. Is this a supposed behavior?Thanks -
3. Re: Is this a jboss bug (entity setter mehod)?
So, it is a one to many relationship from A to B (1 A has many Bs), right?
B table should have a foreign key. Could you describe:
- what data (specifically foreign key) was in table B before and after CMR setter invocation;
- what did the CMR getter return before and after the setter invocation? -
4. Re: Is this a jboss bug (entity setter mehod)?
Yes, it's a 1-to-many relationship.where B has a compound primary key.
say A's Primary Key is PK_A, B's Primary Key is (PK_A,ColB),where ColB is another column in Table B.
The scenario like this:
say table B's structure is like:(PK_A,ColB,ColB2) and we have a row of old data here in table B:(1000,9999,'abcd');where 1000 is a Pk in Table A which is referenced by table B.
In A's EntityEJB ,the CMR setter is setBs(collection bs),when we tried to set a new collection with new data (1000,8888,'efgh') from A's EntityEJB with that setter, then after calling the setter,the result in DB is like:(1000,9999,'abcd') +(1000,8888,'efgh').the old one is still there
The CMR getter seems to get them all.
Any suggestions? -
5. Re: Is this a jboss bug (entity setter mehod)?
Primary key column (PK_A in B) can't be null. You have to remove the related Bs yourself before destroying relationships.
I agree that the exception should be thrown in attempt to set pk column to null. -
6. Re: Is this a jboss bug (entity setter mehod)?
So what you need is either map foreign key to a non-pk column in table B or remove related Bs yourself before clearing relationships.
-
7. Re: Is this a jboss bug (entity setter mehod)?
Alex,
I think the container is to handle the clearance before setting new ones whatever compound Pk exists .So will it be enhanced by Jboss in the near future?Thanks -
8. Re: Is this a jboss bug (entity setter mehod)?
What do you mean by enhancement? The only fix I can think about is to throw an exception whenever you invoke the CMR setter which modifies the primary key. The only way to destroy relationships in your case is to remove B. CMR in this case read-only.
-
9. Re: Is this a jboss bug (entity setter mehod)?
Was this ever resolved? Because the EJB spec (I quote from 2.1) is painfully clear on this point:
"The Bean Provider can thus use the set method to move objects between the collections referenced by cmr-fields of the same relationship type in different instances. The set accessor method, when applied to a cmr-field in a one-to-many relationship thus has the semantics of the java.util.Collection methods clear, followed by addAll, applied to the target collection; and clear, applied to the source collection. It is the responsibility of the container to transfer the contents of the collection
instances in the same transaction context." (p. 152)
The question is rightly asked. The user does _not_ have to clear out the old elements of the collection, the container is obligated to do that before adding the new collection elements. Whether or not the keys are composite or simple doesn't enter into it. I haven't experimented (not so easy to make up a useful example with composite keys), but does the JBoss container (I'm using 3.2.3) not do this?
Thanks for your answer!
David Sills -
10. Re: Is this a jboss bug (entity setter mehod)?
It does. But in this case relationship can't be modified because foreigm key is mapped to the primary key.