Given the following the following two entities
#Entity
public class A {
#Version
protected int version;
String basicPropertey;
// getter and setter for basicProperty
}
#Entity
public class B {
#Version
protected int version;
#ManyToOne
private A a;
public B(A a) {
this.a = a}
}
//getter for a
}
Two questions:
Is there version number of the entity A increased every time the
entity B is merged to the DB (note that there is no
CascadeType.MERGE defined on the relationship to A) and, thus, cause
a possible OptimisticcLockException when A is merged with a
different version number?
If yes, would it help to avoid the likelihood of an
OptimisticLockException if I add #JoinColumn(updatable=false) on the
relationship?
My situation is that entity B is updated very frequently and A sporadically, but only its basic attributes (not the relationship) and I'm getting an OptimisticLockException on the entity A.
If you only change B, then you cannot get a lock error on A.
You will only get a lock error on B.
Check you SQL log to what you are actually doing.
Related
Issue
I have a one to many parent child relationship but when I merge the parent object it is creating a duplicate set of child records.
Details
This is a follow on from JPA OneToMany Only Updates First Time
I am using Eclipse Link and following on from this I now have two classes that look like
#Entity
public class Foo {
#Id
#Column(name="FOO_ID)
private int id;
#Column(name="FOO_NAME")
private String name;
#OneToMany(mappedBy="foo", cascade = CascadeType.ALL)
private List<Bar> bars;
public void addBar(Bar b) {
b.setFoo(this);
bars.add(b);
}
}
#Entity
public class Bar {
#Id
#Column(name="BAR_ID")
private it id;
#Column(name="BAR_NAME")
private String name;
#ManyToOne
#JoinColumn(name="FOO_ID")
private Foo foo;
}
and then I have
public void processBars(Foo foo) {
for (MyListItem i : myList) {
Bar bar = new Bar();
bar.setName("Test");
foo.addBar(bar);
}
entityMgr.merge(foo);
}
and finally
processBars(foo);
if(someCodition) {
foo.setStatus("xxx");
entityMgr.merge(foo);
}
This second merge is then creating a second set of Bars
Sequence, Id and EqualsAndHashCode
I am guessing this is down to the use of database sequences for the ID fields. When Bar is created the ID is obviously null and then for some reason it is checking again after the record has been inserted and deciding it is a different object. I am using Lombok and have added #EqualsAndHashCode annotations to both classes excluding the list of children in 'Foo'
Update
Reworked question as I figured out it was the second merge that is causing the problems
JPA's merge api takes the object passed in and merges it into the context. This is different from persist, which takes the instance passed in and makes it managed - merge will return the managed instance.
Entity e = new Entity();
Entity e1 = em.merge(e);
assertTrue(e1!=e);// they are different instances
when the transaction is flushed/committed, e1 will have its ID set because it was managed by the persistence unit, but 'e' will not. So when you call em.merge(e), you are giving it a blank instance, forcing in duplicates.
Simple solution is to return the resulting Foo from your processBars method and use it for your subsequent changes and merge calls.
First, here are my entities.
Player :
#Entity
#JsonIdentityInfo(generator=ObjectIdGenerators.UUIDGenerator.class,
property="id")
public class Player {
// other fields
#ManyToOne
#JoinColumn(name = "pla_fk_n_teamId")
private Team team;
// methods
}
Team :
#Entity
#JsonIdentityInfo(generator=ObjectIdGenerators.UUIDGenerator.class,
property="id")
public class Team {
// other fields
#OneToMany(mappedBy = "team")
private List<Player> members;
// methods
}
As many topics already stated, you can avoid the StackOverflowExeption in your WebService in many ways with Jackson.
That's cool and all but JPA still constructs an entity with infinite recursion to another entity before the serialization. This is just ugly ans the request takes much longer. Check this screenshot : IntelliJ debugger
Is there a way to fix it ? Knowing that I want different results depending on the endpoint. Examples :
endpoint /teams/{id} => Team={id..., members=[Player={id..., team=null}]}
endpoint /members/{id} => Player={id..., team={id..., members=null}}
Thank you!
EDIT : maybe the question isn't very clear giving the answers I get so I'll try to be more precise.
I know that it is possible to prevent the infinite recursion either with Jackson (#JSONIgnore, #JsonManagedReference/#JSONBackReference etc.) or by doing some mapping into DTO. The problem I still see is this : both of the above are post-query processing. The object that Spring JPA returns will still be (for example) a Team, containing a list of players, containing a team, containing a list of players, etc. etc.
I would like to know if there is a way to tell JPA or the repository (or anything) to not bind entities within entities over and over again?
Here is how I handle this problem in my projects.
I used the concept of data transfer objects, implemented in two version: a full object and a light object.
I define a object containing the referenced entities as List as Dto (data transfer object that only holds serializable values) and I define a object without the referenced entities as Info.
A Info object only hold information about the very entity itself and not about relations.
Now when I deliver a Dto object over a REST API, I simply put Info objects for the references.
Let's assume I deliever a PlayerDto over GET /players/1:
public class PlayerDto{
private String playerName;
private String playercountry;
private TeamInfo;
}
Whereas the TeamInfo object looks like
public class TeamInfo {
private String teamName;
private String teamColor;
}
compared to a TeamDto
public class TeamDto{
private String teamName;
private String teamColor;
private List<PlayerInfo> players;
}
This avoids an endless serialization and also makes a logical end for your rest resources as other wise you should be able to GET /player/1/team/player/1/team
Additionally, the concept clearly separates the data layer from the client layer (in this case the REST API), as you don't pass the actually entity object to the interface. For this, you convert the actual entity inside your service layer to a Dto or Info. I use http://modelmapper.org/ for this, as it's super easy (one short method call).
Also I fetch all referenced entities lazily. My service method which gets the entity and converts it to the Dto there for runs inside of a transaction scope, which is good practice anyway.
Lazy fetching
To tell JPA to fetch a entity lazily, simply modify your relationship annotation by defining the fetch type. The default value for this is fetch = FetchType.EAGER which in your situation is problematic. That is why you should change it to fetch = FetchType.LAZY
public class TeamEntity {
#OneToMany(mappedBy = "team",fetch = FetchType.LAZY)
private List<PlayerEntity> members;
}
Likewise the Player
public class PlayerEntity {
#ManyToOne(fetch = FetchType.LAZY)
#JoinColumn(name = "pla_fk_n_teamId")
private TeamEntity team;
}
When calling your repository method from your service layer, it is important, that this is happening within a #Transactional scope, otherwise, you won't be able to get the lazily referenced entity. Which would look like this:
#Transactional(readOnly = true)
public TeamDto getTeamByName(String teamName){
TeamEntity entity= teamRepository.getTeamByName(teamName);
return modelMapper.map(entity,TeamDto.class);
}
In my case I realized I did not need a bidirectional (One To Many-Many To One) relationship.
This fixed my issue:
// Team Class:
#OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
private Set<Player> members = new HashSet<Player>();
// Player Class - These three lines removed:
// #ManyToOne
// #JoinColumn(name = "pla_fk_n_teamId")
// private Team team;
Project Lombok might also produce this issue. Try adding #ToString and #EqualsAndHashCode if you are using Lombok.
#Data
#Entity
#EqualsAndHashCode(exclude = { "members"}) // This,
#ToString(exclude = { "members"}) // and this
public class Team implements Serializable {
// ...
This is a nice guide on infinite recursion annotations https://www.baeldung.com/jackson-bidirectional-relationships-and-infinite-recursion
You can use #JsonIgnoreProperties annotation to avoid infinite loop, like this:
#JsonIgnoreProperties("members")
private Team team;
or like this:
#JsonIgnoreProperties("team")
private List<Player> members;
or both.
I am working on an application using Hibernate and I want to delete some records in the database. The relevant Entities are:
#Entity
public class Product {
private String serialNumber;
private Set<Part> parts = new HashSet<Part>();
#Id
public String getSerialNumber() { return serialNumber; }
void setSerialNumber(String sn) { serialNumber = sn; }
#OneToMany
public Set<Part> getParts() { return parts; }
void setParts(Set parts) { this.parts = parts; }
...
}
#Entity
public class Part implements Serializable {
#Id
#GeneratedValue
private Long part_id;
private String userCode = "";
//getters and setters
....
}
I have let Eclipse implement equals and hashCode in Entity Part based on part_id and userCode. There is also an Entity Factory from which 'begin' all the associations to the other Entities. Therefore, in order to save all the changes it only necessary to execute the comand:
session.update(factory);
All the changes are saved successfully except from the delete from parts. I do:
products.getParts.remove(part);
The issues comig out are:
1) In some cases is part from the Set not removed although the comparison to a part in the Set with equals true returns (the part is in Set according to equals but it is not removed)
2) Even if the remove in the Set succeeds, the record in the database is not deleted.
Based on the above ascertainments what is the best way to remove the records in this case using not loads of queries?
You need to explicitly remove the child:
session.delete(part);
From Hibernate Docs:
The following code:
Parent p = (Parent) session.load(Parent.class, pid);
Child c = (Child) p.getChildren().iterator().next();
p.getChildren().remove(c);
c.setParent(null);
session.flush();
will not remove c from the database. In this case, it will only remove
the link to p and cause a NOT NULL constraint violation. You need to
explicitly delete() the Child.
Parent p = (Parent) session.load(Parent.class, pid);
Child c = (Child) p.getChildren().iterator().next();
p.getChildren().remove(c);
session.delete(c);
session.flush();
When using hibernate to map relationships you must be aware of two main concerns:
Which is the owner of the relationship? The owner is the side of the relation whose changes will be persisted in database. In your case the owner is the Part object.
Is a true parent/child relationship or simply a composition relationship? In your case I think the answer is composition
If you want to manage the relation using the set, you have two options:
use #ElementCollection instead of #OnetoMany
change ownership. Something like this:
#OneToMany
#JoinColumn(name="part_id")
public Set<Part> getParts() { return parts; }
void setParts(Set parts) { this.parts = parts; }
However, the second option is not recommended here. See section 2.2.5.3.1.2.
I'm having some issues getting a bidirectional one-to-many association working with JoinTables. This is what I got:
Class A:
#OneToMany
#JoinTable(name="join_table",
JoinColumns={#JoinColumn(name="a_id")},
inverseJoinColumns={#JoinColumn(name="b_id")}
)
#Cascade(org.hibernate.annotations.CascadeType.ALL)
public Set<B> getBs() {
return bs;
}
Class B:
#ManyToOne
#JoinTable(name="join_table",
joinColumns={#JoinColumn(name="b_id", insertable=false,updatable=false)},
inverseJoinColumns={#JoinColumn(name="a_id", insertable=false,updatable=false)})
public A getA() {
return a;
}
If I create a instance of A and B, add the instance of B to A and save. It works. But when I reload the instance of A and try and access the set of Bs it throws a LazyInitializationError with the message "illegal access to loading collection ".
Where am I going wrong here? :) Can anybody point me to a example of bidirectional association which uses a join table. And where the ownership is kept to Class A, I have searched though the documentation at hibernate.org but I cant seem to find it.
-Daniel
Your mapping are proper and that's why the entry is getting saved in the Database. The issue in fetching is because of the Lazy Initialization.
To solve it modify mapping of the class A as,
#OneToMany(fetch=FetchType.LAZY)
#JoinTable(name="join_table",
joinColumns={#JoinColumn(name="a_id")},
inverseJoinColumns={#JoinColumn(name="b_id")}
)
#Cascade(org.hibernate.annotations.CascadeType.ALL)
public Set<B> getBs() {
return bs;
}
This will fire an additional query to the table B and initialize the collection. It might affect the performance depending on the no of entries in your defendant table.
Read the API here for more information.
I have 2 objects joined together defined as such:
public class A {
...
#Id
#Column(name = "A_ID")
#SequenceGenerator(...)
#GeneratedValue(...)
public Long getA_ID();
#OneToOne(mappedBy = "a", fetch = FetchType.LAZY, cascade = CascadeType.ALL, targetEntity = B.class)
public B getB();
...
}
#VirtualAccessMethods(get = "getMethod", set = "setMethod")
public class B {
...
#Id
public Long getA_ID();
#MapsId
#OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL ,targetEntity = A.class)
#JoinColumn(name="A_ID")
public A getA();
getMethod(String name);
setMethod(String name, Object value);
...
}
When I go to em.merge(A) with B joined onto A for an INSERT, everything works fine. However if I do the same thing for an update, it will update only A. The update logic is like so:
#Transactional
public void update(Object fieldOnANewValue, Object fieldOnBNewField) {
A objA = em.executeQuery(...) //loads objA by primary key
objA.setFieldOnA(fieldOnANewValue);
B objB = objA.getB(); //lazy loads objB
objB.setMethod("FieldOnB", fieldOnBNewValue);
}
If I look at the logs, there is a SQL UPDATE statement committing the changes I made to A, but nothing for B. If I manually call em.merge(objB) the same issue exists. Does anyone know exactly what EclipseLink does to determine whether or not to generate an UPDATE statement? Particularly with regard to #VirtualAccessMethods? However, I have had the #OneToOne mappings setup differently before and em.merge(objB) worked fine then, plus INSERT works, so I'm not sure if that's the issue. On the flip side, if I have another object that is also joined onto A, but just is a normal POJO like A is, the UPDATE statement is generated for that. Caching is turned off, and I've verified that the objects are updated correctly before merge is called.
Please show the complete code and mappings.
Given you are using virtual access (are you using this correctly?), it could be some sort of change tracking issue related to the virtual access. Does the issue occur without using virtual access?
Try setting,
#ChangeTracking(ChangeTrackingType.DEFERRED)
to see if this has an affect.
You could also try,
#InstantiationCopyPolicy