[JBoss JIRA] Created: (EJBTHREE-941) merge issue when removing from OneToMany in detached state (layered architecture)
5:14 p.m.
merge issue when removing from OneToMany in detached state (layered architecture)
---------------------------------------------------------------------------------
Key: EJBTHREE-941
URL: http://jira.jboss.com/jira/browse/EJBTHREE-941
Project: EJB 3.0
Issue Type: Bug
Affects Versions: AS 4.2.0 CR1
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:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:52 p.m.
New subject: [JBoss JIRA] Commented: (EJBTHREE-941) merge issue when removing from OneToMany in detached state (layered architecture)
[ http://jira.jboss.com/jira/browse/EJBTHREE-941?page=comments#action_12359211 ]
Rico Apfelbeck commented on EJBTHREE-941:
-----------------------------------------
Someone described our problem in length in the Java developer forum:
http://forum.java.sun.com/thread.jspa?threadID=5145294&tstart=210
merge issue when removing from OneToMany in detached state (layered
architecture)
---------------------------------------------------------------------------------
Key: EJBTHREE-941
URL: http://jira.jboss.com/jira/browse/EJBTHREE-941
Project: EJB 3.0
Issue Type: Bug
Affects Versions: AS 4.2.0 CR1
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:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:46 p.m.
New subject: [JBoss JIRA] Commented: (EJBTHREE-941) merge issue when removing from OneToMany in detached state (layered architecture)
[ http://jira.jboss.com/jira/browse/EJBTHREE-941?page=comments#action_12362642 ]
Ralf Schmoll commented on EJBTHREE-941:
---------------------------------------
I think this is also discussed elsewhere as "JPA missing hibernate's
"delete-orhpan" cascading type" issue.
merge issue when removing from OneToMany in detached state (layered
architecture)
---------------------------------------------------------------------------------
Key: EJBTHREE-941
URL: http://jira.jboss.com/jira/browse/EJBTHREE-941
Project: EJB 3.0
Issue Type: Bug
Affects Versions: AS 4.2.0 CR1
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:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:34 a.m.
New subject: [JBoss JIRA] Commented: (EJBTHREE-941) merge issue when removing from OneToMany in detached state (layered architecture)
[ http://jira.jboss.com/jira/browse/EJBTHREE-941?page=comments#action_12388867 ]
Barak Merimovich commented on EJBTHREE-941:
-------------------------------------------
While the behavior displayed in JBoss seems compatible with the JPA spec, it would be
REALLY good to support both options, i.e. allow for the deleting of child entities in the
DB during a merge.
Perhaps merge is the wrong name for the operation. Maybe 'mirror' is a better one,
or 'sync'.
merge issue when removing from OneToMany in detached state (layered
architecture)
---------------------------------------------------------------------------------
Key: EJBTHREE-941
URL: http://jira.jboss.com/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:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:55 p.m.
New subject: [JBoss JIRA] Commented: (EJBTHREE-941) merge issue when removing from OneToMany in detached state (layered architecture)
[
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
5249
days inactive
6233
days old
4 comments
4 participants
participants (4)
-
Barak Merimovich (JIRA) -
Ralf Schmoll (JIRA)
-
Raphael A BEREHOUDOUHOU (JIRA)
-
Rico Apfelbeck (JIRA)