I have two entities connected with a bidirectional OneToMany/ManyToOne relationship.
#Entity
class One {
#OneToMany(mappedBy = "one", orphanRemoval = true, fetch = FetchType.EAGER)
private Set<Many> manies;
// ...
}
#Entity
class Many {
#ManyToOne
#JoinColumn(name = "one_id", nullable = false)
private One one;
// ...
}
When I want to remove a Many instance, I remove it from its One's manies Set and delete it from the database. If I take the same One instance and save it again (because I changed anything, it doesn't have to be related to the relationship), I get an exception:
javax.persistence.EntityNotFoundException: Unable to find test.Many with id 12345
The ID (in this example 12345) is the ID of the just removed entity. Note that removal of the entity 12345 succeeded: The transaction commits successfully and the row is removed from the database.
Adding and removing instances is done with Spring Data repositories. Removing looks more or less like this:
one.getManies().remove(manyToRemove);
oneDao.save(one);
manyDao.delete(manyToRemove);
I debugged a little and found out that the Set is a Hibernate PersistentSet which contains a field storedSnapshot. This in turn is another Set that still references the removed entity. I have no idea why this reference is not removed from the snapshot but I suspect this is the problem: I think Hibernate tries to remove the entity a second time because it's in the snapshot but not in the actual collection. I searched for quite a while but I didn't encounter others with a similar problem.
I use Hibernate 4.2.2 and Spring Data 1.6.0.
Am I doing something inherently wrong? How can I fix this?
I'm having the same problem.
A workaround is to replace the entire collection.
Set<Many> maniesBkp = one.getManies(); // Instance of PersistentSet
maniesBkp.remove(manyToRemove);
Set<Many> manies = new HashSet<Many>();
manies.addAll(maniesBkp);
one.setManies(manies);
...
manyDao.delete(manyToRemove);
...
oneDao.save(one);
As your #OneToMany relation has orphanRemoval = true, you don't have to explicitly remove the child element from the database - just remove it from the collection and save the parent element.
Try add CascadeType.REMOVE and orphanRemoval
#OneToMany(mappedBy = "one", orphanRemoval = true, fetch = FetchType.EAGER, cascade = CascadeType.REMOVE, orphanRemoval = true)
Than perform delete following
one.getManies().remove(manyToRemove);
oneDao.save(one);
Edited:
I have created POC, look on the UserRepositoryIntegrationTest.departmentTestCase (code)
Related
Let's say I have following model structure:
#Entity
#Table(....)
public class AnnotationGroup{
...
private List<AnnotationOption> options;
#OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, orphanRemoval = true)
#JoinColumn(name = "annotation_group_id", nullable = false)
public List<AnnotationOption> getOptions() {
return options;
}
}
#Entity
#Table(...)
public class AnnotationOption {
private Long id;
#Id
#GeneratedValue(strategy = GenerationType.IDENTITY)
#Override
public Long getId() {
return id;
}
}
At the moment I have group1 with AnnotationOptions opt1 opt2 and opt3
Then I want to replace all option with only one option opt1
Additionally I have constraint in database:
CONSTRAINT "UQ_ANNOTATION_OPTION_name_annotation_group_id" UNIQUE (annotation_option_name, annotation_group_id)
And this one fires:
Caused by: org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint "UQ_ANNOTATION_OPTION_name_annotation_group_id"
Detail: Key (name, annotation_group_id)=(opt1, 3) already exists.
Actually isuue that hibernate removes orphans after update.
Can you suggest something t resolve issue?
There are so many things that are wrong in this example:
EAGER fetching on the #OneToManycollection is almost always a bad idea.
Unidirectional collections are also bad, use the bidirectional one.
If you get this exception, most likely you cleared all the elements and re-added back the ones that you want to be retained.
The best way to fix it is to explicitly merge the existing set of children with the incoming ones so that:
New child entities are being added to the collection.
The child entities that are no longer needed are removed.
The child entities matching the business key (annotation_group_name, study_id) are updated with the incoming data.
According to Hibernate documentation hibernate perform in the following order to preserve foreign-key constraint:
Inserts, in the order they were performed
Updates
Deletion of collection elements
Insertion of collection elements
Deletes, in the order they were performed
For your special need you should manually flush the transaction to force the deletion in database before.
I have a ManyToMany-relation between student and teacher in a Student_Teacher-table (Entityless).
Student: Teacher(owning-side): Student_Teacher
1= Tim 50= Mrs. Foo 1= 1 50
2= Ann 51= Mr. Bar 2= 1 51
3= 2 50
4= 2 51
As you see above every Student is currently related to every Teacher.
Now I like to remove Ann and I like to use the database's cascading techique to remove entries from the Student_Teacher-table but I do neither like to remove other Students, nor Teacher, nor other relationship.
This is what I have in the Student-Entity:
#ManyToMany(mappedBy="students")
public Set<Teacher> getTeachers() {
return teachers;
}
This is what I have in the Teacher-Entity:
#ManyToMany
#JoinTable(name="Student_Teacher", joinColumns = {
#JoinColumn(name="StudentID", referencedColumnName = "TeacherID", nullable = false)
}, inverseJoinColumns = {
#JoinColumn(name="TeacherID", referencedColumnName = "StudentID", nullable = false)
})
public Set<Student> getStudents() {
return students;
}
Now I like to use the database's delete cascade functionality. I repeat: The database's delete cascade functionality targeting the Student_Teacher-table only!
The problem:
org.h2.jdbc.JdbcSQLException: Referentielle Integrität verletzt: "FK_43PMYXR2NU005M2VNEB99VX0X: PUBLIC.Student_Teacher FOREIGN KEY(StudentID) REFERENCES PUBLIC.Student(StudentID) (2)"
Referential integrity constraint violation: "FK_43PMYXR2NU005M2VNEB99VX0X: PUBLIC.Student_Teacher FOREIGN KEY(StudentID) REFERENCES PUBLIC.Student(StudentID) (2)"; SQL statement:
delete from "Student" where name='Ann'
at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
at org.h2.message.DbException.get(DbException.java:179)
at org.h2.message.DbException.get(DbException.java:155)
at org.h2.constraint.ConstraintReferential.checkRow(ConstraintReferential.java:425)
What i can not use is the
#ManyToMany(cascade={CascadeType.REMOVE})
Because of the documetation tells me:
(Optional) The operations that must be cascaded to the target of the association.
The "target" is the Teacher, so this cascade would remove the Teacher (what I do not like to remove).
Question:
How to configure the entitys to remove Ann and the relation only using the database's cascade functionality?
Proof of Concept:
I tried another feature, I have noticed the possibility to configure the foreign-key nativly like this:
#ManyToMany(cascade = { CascadeType.REMOVE })
#JoinTable(name="Student_Teacher", joinColumns = {
#JoinColumn(name="StudentID", referencedColumnName = "TeacherID", nullable = false, foreignKey=#ForeignKey(foreignKeyDefinition="FOREIGN KEY (StudentID) REFERENCES Student ON DELETE NO ACTION"))
}, inverseJoinColumns = {
#JoinColumn(name="TeacherID", referencedColumnName = "StudentID", nullable = false, foreignKey=#ForeignKey(foreignKeyDefinition="FOREIGN KEY (TeacherID) REFERENCES Teacher ON DELETE NO ACTION"))
})
public Set<Student> getStudents() {
return students;
}
The problem is: This works fine but to trigger the removal of the entries in Student_Teacher I have to specify #ManyToMany(cascade = { CascadeType.REMOVE }) on both sides. Hibernate do not parse the foreignKeyDefinition and only see the CascadeType.REMOVE and drops the target-entitys (and the referenced Student Tim) out of the cache, but they are still in the database!!! So I have to clear the hibernate-session immendentelly after drop to re-read the existence of the Teachers Mrs. Foo and Mr. Bar and the Student Tim.
Now I like to use the database's delete cascade functionality. I
repeat: The database's delete cascade functionality targeting the
Student_Teacher-table only!
Simply define the cascade deletion on the database schema level, and the database would do it automatically. However, if the owning side of the association is loaded/manipulated in the same persistence context instance, then the persistence context will obviously be in an inconsistent state resulting in issues when managing the owning side, as Hibernate can't know what is done behind its back. Things get even more complicated if second-level caching is enabled.
So you can do it and take care not to load Teachers in the same session, but I don't recommend this and I write this only as an answer to this part of the question.
How to configure the entities to remove Ann and the relation only
using the database's cascade functionality?
There is no such configuration on JPA/Hibernate level. Most DDL declarations in mappings are used only for automatic schema generation, and are ignored when it comes to entity instances lifecycle and association management.
What i can not use is the
#ManyToMany(cascade={CascadeType.REMOVE})
Cascading of entity lifecycle operations and association management are two different notions that are completely independent of each other. Here you considered the former while you need the latter.
The problem you're facing is that you want to break the association from the Student (inverse side marked with mappedBy) when the Teacher is the owning side. You can do it by removing the student from all teachers to which it is associated, but that could lead to loading lots of data (all associated teachers with all their students). That's why introducing a separate entity for the association table could be a good compromise, as already suggested by #Mark, and as I suggested as well in some of my previous answers on similar topics together with some other potential improvements.
You may create a new entity TeacherStudent for the relationship, and then use CascadeType.REMOVE safely:
#Entity
public class Student {
#OneToMany(mappedBy="student",cascade={CascadeType.REMOVE})
public Set<TeacherStudent> teacherStudents;
}
#Entity
public class Teacher {
#OneToMany(mappedBy="teacher",cascade={CascadeType.REMOVE})
public Set<TeacherStudent> teacherStudents;
}
#Entity
public class TeacherStudent {
#ManyToOne
public Teacher teacher;
#ManyToOne
public Student student;
}
You'll have to take care of the composite foreign key for TeacherStudent. You may take a look at https://stackoverflow.com/a/29116687/3670143 for that.
Another relevant thread about ON DELETE CASCADE is JPA + Hibernate: How to define a constraint having ON DELETE CASCADE
As you see above every Student is related to every Teacher.
The point is when in a situation where "every A is related to every B", then there is no need to have a many to many table to keep such relationship. Since logically A and B is independent to each other in this situation. Adding/Deleting/Modifying A makes no effect on B and vice versa. This behaviour is exactly what you are after, because you want the cascading operations stop at the relation table:
delete cascade functionality targeting the Student_Teacher-table only!
Relationship table is only useful when in situation where "every A is related to a subset of B".
So to solve your problem is actually a fairly one: Drop the Student_Teacher table.
As we had a similar problem but finally solved it another way, here is our solution :
We replaced
#ManyToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
in our relationship with
#ManyToMany(fetch = FetchType.LAZY, cascade = {
CascadeType.DETACH,
CascadeType.MERGE,
CascadeType.REFRESH,
CascadeType.PERSIST
})
and it successfully removed the association without removing linked entity.
I have a JPA Entities like this:
#Entity
class MyEntity{
#JsonIgnore
#OneToMany(mappedBy = "application", cascade = ALL, fetch = LAZY)
private List<MyChildEnity> myChildEntities;
}
...
#Entity
class MyChildEnity {
#ManyToOne(optional = false, fetch = FetchType.LAZY, cascade = { REFRESH,
DETACH })
#JoinColumn(name = "APPLICATION_ID")
private MyEntity application;
}
I access this entity from a REST call. When the number of elements is very large, and I try to delete the MyEntity Object the REST call hangs and then timeout. For small number of elements in MyChildEnity table it works fine. When I debugged, I saw that JPA fetches one record at a time and deletes it. This is too slow and too much work done.
Is this an expected behavior? Shouldn't JPA be intelligent to convert this to a single DELETE call on the MyChildEnity table.
I'm using OpenJPA with Derby and DB2 database.
The reason why you get one delete statement for each element probably has something to do with the fact that JPA let you do something pre- and post removal. If you write a JPQL with a deletestatement you are able to bypass the callback mechanism and delete everything in a single request.
Documentation for entity listeners and callbacks. (This is JPA functionality).
I had following entities in my project:
AccountGroup
AccountItem
AccountSegment
With folowing relations:
AccountGroup has List<AccountItem>
AccountItem had List<AccountSegment>
and everything worked fine.
When I changed last relation to:
AccountItem has Set<AccountSegment>
AccountGroup object read from database looks strange. If given AccountItem had three AccountSegments, then I have three the same AccountItems in AccountGroup.
A shot from debugger can possibly tell it better than I can:
As you can see, accountMapperItems list has four positions instead of two. First pair is a duplicate each having the same variables. (second is similar, not shown on screenshot).
Below I paste entities code fragments:
class AccountGroup {
...
#OneToMany(fetch = FetchType.EAGER, cascade = CascadeType.ALL, orphanRemoval = true, mappedBy = "group")
private List<AccountItem> accountMapperItems;
....
}
class AccountItem {
...
#ManyToMany(fetch = FetchType.EAGER, cascade = { CascadeType.REFRESH, CascadeType.MERGE })
#JoinTable(
joinColumns={#JoinColumn(name="ACCOUNT_ITEM_ID", referencedColumnName="ID")},
inverseJoinColumns={#JoinColumn(name="SEGMENT_ID", referencedColumnName="ID")})
private Set<Segment> segmentSet;
#ManyToOne
private AccountGroup group;
...
}
AccountSegment does not have any links.
Does anyone know why is it retriving accountMapperItems list one position per AccountSegment?
The problem is not duplicate entries in jointable! I have double checked it.
Update
#Fetch (FetchMode.SELECT)
solved the case, further explanations are available in post mentioned in the answer.
Make sure all your entities implement hashCode() and equals(). These methods are used by some collections (like Sets) to uniquely identify elements.
Edit: If that doesn't solve it, then I think the duplicates are most likely caused by the FetchType.EAGER. This answer explains it well. Try removing the FetchType.EAGER to see if it makes any difference.
I have the following mapping:
#Entity
#Table(name = "Prequalifications")
public class Prequalification implements Serializable
{
...
#ManyToMany
#JoinTable(name = "Partnerships", joinColumns = #JoinColumn(name = "prequalification_id", referencedColumnName = "id"), inverseJoinColumns = #JoinColumn(name = "company_id", referencedColumnName = "id"))
private Set<Company> companies;
...
}
In a #ManyToMany + #JoinTable mapped relationship, isn't it kind of implicit that the association (link) entities (here Partnerships) are automatically persisted, removed, etc. even though
by default, relationships have an empty cascade set
? The above quote was taken from "Pro JPA 2, by Mike Keith".
Executing
em.merge(prequalification);
on the above entity does persist the associated partnerships without any cascade types specified.
Am I correct that this implicit cascade has to be performed? This isn't mentioned anywhere I looked...
The rows in the join table will be inserted/deleted as part of the owning Entity (if bi-directional the side without the mappedBy). So if you persist or remove or update the Prequalification the join table rows will also be inserted or deleted.
The target Company objects will not be cascaded to. So on remove() they will not be deleted, if the list is updated they will not be deleted unless orphanRemovla is set. Persist should also not be cascaded, but what happens when you have references to "detached" objects is somewhat of a grey area. Technically an error should be thrown, because the object is new and the relationship was not cascade persist. It may also try to insert and get a constraint error. It should not cascade the persist, although your object model is technically in an invalid state, so what occurs may depend on the provider.
Wanted to add a comment, but don't have enough rep for it.
I had the same question as #D-Dᴙum: "Where in the docs can we find a reference to this behaviour?"
I found it in the Hibernate docs (many-to-many).
If you scroll just a bit just below the code example there, you will find:
When an entity is removed from the #ManyToMany collection, Hibernate simply deletes the joining record in the link table. Unfortunately, this operation requires removing all entries associated with a given parent and recreating the ones that are listed in the current running persistent context.
Where the "link table" refers to the "join table".
Hope this helps.