[
https://jira.jboss.org/jira/browse/EJBTHREE-941?page=com.atlassian.jira.p...
]
Raphael A BEREHOUDOUHOU commented on EJBTHREE-941:
--------------------------------------------------
If this is the JPA Spec, then surely there should be a bug against the Spec. I don't
think the issue is about deleting the orphans. The can remain in the DB as far as the
'link' between A and B is removed ! So when an entity B is not in the Set anynore,
this means the relationship has been remove, and hence the FK (of line if a relationship
table is being used) should be removed.
Remove the entity is something different all together. This is a Hibernate bug IMHO. It is
about removing the relatioship (not the entities) . Should be easy to fix as it seems to
work fine for when the collection is a List ! Unfortunately, I have have several
Collections in my entity, and the only way I can get them to Fetch Eagerly is by using
Set. (Another hibernate bug with Eagerky fetching multiple collections !).
merge issue when removing from OneToMany in detached state (layered
architecture)
---------------------------------------------------------------------------------
Key: EJBTHREE-941
URL:
https://jira.jboss.org/jira/browse/EJBTHREE-941
Project: EJB 3.0
Issue Type: Bug
Affects Versions: AS 4.2.0 GA
Environment: 13:37:59,625 INFO [ServerInfo] Java version: 1.5.0_09,Sun
Microsystems Inc.
13:37:59,625 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.5.0_09-b01,Sun
Microsystems Inc.
13:37:59,625 INFO [ServerInfo] OS-System: Windows XP 5.1,x86
Reporter: Rico Apfelbeck
We work on a client-server environment with a webstart-client with an own JVM. Only the
server has access to the JPA. POJOs are transfered from client to server and back.
Our Issue occurs in the following workflow:
- We get an Object A on the server from the Entitymanager and transfer it to the client.
- This Object has a OneToMany-relation to some Objects B (fetchtype: EAGER, cascade:
ALL). In B we have a reference to A.
- On the client we remove in A some B from the Set, for example with clean() and transfer
A back to the server.
- We merge A on the server.
- There is no exception thrown.
The returned A from the merge-call does not contain any B, reloading A by Id results in a
restored list containing the removed Bs.
While added new Bs to A are stored correctly, removing them doesn't result in the
deletion of the removed Bs from the database.
Updating B in the List in A results in updated Bs when merging A.
Only the removal causes problems. We assume that the problem comes from checking the now
empty list against the database.
Reloading A before merging in the server and manually compare the List of Bs, using
EntityManager.remove() when neccesary. helps our case, but that's not the way it shoud
be. :)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira