What exactly does JPA's fetch strategy control? I can't detect any difference between eager and lazy. In both cases JPA/Hibernate does not automatically join many-to-one relationships.
Example: Person has a single address. An address can belong to many people. The JPA annotated entity classes look like:
#Entity
public class Person {
#Id
public Integer id;
public String name;
#ManyToOne(fetch=FetchType.LAZY or EAGER)
public Address address;
}
#Entity
public class Address {
#Id
public Integer id;
public String name;
}
If I use the JPA query:
select p from Person p where ...
JPA/Hibernate generates one SQL query to select from Person table, and then a distinct address query for each person:
select ... from Person where ...
select ... from Address where id=1
select ... from Address where id=2
select ... from Address where id=3
This is very bad for large result sets. If there are 1000 people it generates 1001 queries (1 from Person and 1000 distinct from Address). I know this because I'm looking at MySQL's query log. It was my understanding that setting address's fetch type to eager will cause JPA/Hibernate to automatically query with a join. However, regardless of the fetch type, it still generates distinct queries for relationships.
Only when I explicitly tell it to join does it actually join:
select p, a from Person p left join p.address a where ...
Am I missing something here? I now have to hand code every query so that it left joins the many-to-one relationships. I'm using Hibernate's JPA implementation with MySQL.
Edit: It appears (see Hibernate FAQ here and here) that FetchType does not impact JPA queries. So in my case I have explicitly tell it to join.
JPA doesn't provide any specification on mapping annotations to select fetch strategy. In general, related entities can be fetched in any one of the ways given below
SELECT => one query for root entities + one query for related mapped entity/collection of each root entity = (n+1) queries
SUBSELECT => one query for root entities + second query for related mapped entity/collection of all root entities retrieved in first query = 2 queries
JOIN => one query to fetch both root entities and all of their mapped entity/collection = 1 query
So SELECT and JOIN are two extremes and SUBSELECT falls in between. One can choose suitable strategy based on her/his domain model.
By default SELECT is used by both JPA/EclipseLink and Hibernate. This can be overridden by using:
#Fetch(FetchMode.JOIN)
#Fetch(FetchMode.SUBSELECT)
in Hibernate. It also allows to set SELECT mode explicitly using #Fetch(FetchMode.SELECT) which can be tuned by using batch size e.g. #BatchSize(size=10).
Corresponding annotations in EclipseLink are:
#JoinFetch
#BatchFetch
"mxc" is right. fetchType just specifies when the relation should be resolved.
To optimize eager loading by using an outer join you have to add
#Fetch(FetchMode.JOIN)
to your field. This is a hibernate specific annotation.
The fetchType attribute controls whether the annotated field is fetched immediately when the primary entity is fetched. It does not necessarily dictate how the fetch statement is constructed, the actual sql implementation depends on the provider you are using toplink/hibernate etc.
If you set fetchType=EAGER This means that the annotated field is populated with its values at the same time as the other fields in the entity. So if you open an entitymanager retrieve your person objects and then close the entitymanager, subsequently doing a person.address will not result in a lazy load exception being thrown.
If you set fetchType=LAZY the field is only populated when it is accessed. If you have closed the entitymanager by then a lazy load exception will be thrown if you do a person.address. To load the field you need to put the entity back into an entitymangers context with em.merge(), then do the field access and then close the entitymanager.
You might want lazy loading when constructing a customer class with a collection for customer orders. If you retrieved every order for a customer when you wanted to get a customer list this may be a expensive database operation when you only looking for customer name and contact details. Best to leave the db access till later.
For the second part of the question - how to get hibernate to generate optimised SQL?
Hibernate should allow you to provide hints as to how to construct the most efficient query but I suspect there is something wrong with your table construction. Is the relationship established in the tables? Hibernate may have decided that a simple query will be quicker than a join especially if indexes etc are missing.
Try with:
select p from Person p left join FETCH p.address a where...
It works for me in a similar with JPA2/EclipseLink, but it seems this feature is present in JPA1 too:
If you use EclipseLink instead of Hibernate you can optimize your queries by "query hints". See this article from the Eclipse Wiki: EclipseLink/Examples/JPA/QueryOptimization.
There is a chapter about "Joined Reading".
to join you can do multiple things (using eclipselink)
in jpql you can do left join fetch
in named query you can specify query hint
in TypedQuery you can say something like
query.setHint("eclipselink.join-fetch", "e.projects.milestones");
there is also batch fetch hint
query.setHint("eclipselink.batch", "e.address");
see
http://java-persistence-performance.blogspot.com/2010/08/batch-fetching-optimizing-object-graph.html
I had exactly this problem with the exception that the Person class had a embedded key class.
My own solution was to join them in the query AND remove
#Fetch(FetchMode.JOIN)
My embedded id class:
#Embeddable
public class MessageRecipientId implements Serializable {
#ManyToOne(targetEntity = Message.class, fetch = FetchType.LAZY)
#JoinColumn(name="messageId")
private Message message;
private String governmentId;
public MessageRecipientId() {
}
public Message getMessage() {
return message;
}
public void setMessage(Message message) {
this.message = message;
}
public String getGovernmentId() {
return governmentId;
}
public void setGovernmentId(String governmentId) {
this.governmentId = governmentId;
}
public MessageRecipientId(Message message, GovernmentId governmentId) {
this.message = message;
this.governmentId = governmentId.getValue();
}
}
Two things occur to me.
First, are you sure you mean ManyToOne for address? That means multiple people will have the same address. If it's edited for one of them, it'll be edited for all of them. Is that your intent? 99% of the time addresses are "private" (in the sense that they belong to only one person).
Secondly, do you have any other eager relationships on the Person entity? If I recall correctly, Hibernate can only handle one eager relationship on an entity but that is possibly outdated information.
I say that because your understanding of how this should work is essentially correct from where I'm sitting.
Related
Following entities:
#Table
class AA1 {
#Id
Long id;
String a_number;
Category category;
#ManyToOne(fetch = FetchType.LAZY)
#JoinColumn(name= 'a_number', referencedColumnName='a_number')
#JoinColumn(name= 'category', referencedColumnName='category')
BB1 bb1
...other fields...
}
#Table
class BB1 {
#Id
String a_number;
Category category;
String value;
}
JPQL query:
SELECT a FROM AA1 a LEFT JOIN a.bb1 b;
Hibernate produces correct sql query, but when it tries to collect data it makes additional call like:
SELECT b.a_number, b.category, b.value FROM BB1 b WHERE b.a_number = ? AND b.category = ?
I checked that query returns null.
How can I avoid such database queries?
My investigation: As far as I see Hibernate creates key by(AA1.a_number and AA1.category) and tries to retrieve entity from context. And for specific row 'left join' query returns null values and Hibernate asks context by key and context returns null, it leads to call to database for it.
You must add FETCH to your JPQL query :
SELECT a FROM AA1 a LEFT JOIN FETCH a.bb1 b;
but keep the LAZY loading, because Hibernante will always try to get ManyToOne or OneToOne relationship, which are EAGER by default, with an additional query.
Look at this article https://thorben-janssen.com/5-common-hibernate-mistakes-that-cause-dozens-of-unexpected-queries/ from Th
By default, to make lazy loading work for #OneToOne and #ManyToOne, you need to enable "no proxy lazy associations". Otherwize, despite the FetchType.LAZY annotation, the associated object will be "fetched" and the "fetch" will be done with an extra sql query.
Therefore, one half-way solution to leverage performances without enabling "no proxy lazy associations" is to avoid extra queries by forcing a join fetch on the associated objet. Various technics allow to reach this goal : "LEFT JOIN FETCH" in JPQL queries or EntityGraph.
Just looking at the entity definition #ManyToOne(fetch = FetchType.LAZY) is the cause.
You are explicitly telling JPA to fetch BB1 only when it is needed/accessed.Hence when the first call to get the parent entity is made BB1 is not loaded.It is only when you are accessing the child that triggers JPA to fetch it.
If you change it to FetchType.EAGER , both the entities will be queried in a single call.
But be careful there are advantages/pit-falls with either approach.
Read more abt it here : https://thorben-janssen.com/entity-mappings-introduction-jpa-fetchtypes/
I hope someone have experienced something similar and can help me:
I am using graphql-java (and spring, graphql-java-tools etc.) and hibernate and I am experiencing a weird issue:
Whenever i execute a query (or mutation) and load an entity via Hibernate, it automatically lazy loads the relations. I can see this when looking in Hibernates query log.
This happens even though i dont load the field in the query, and even also when i delete the field from the schema altogether.
Example, given the following schema:
query {
getAllItems: [Item!]!
}
Item {
id: String!
name: String!
owner: Person!
}
Person {
id: String!
name: String!
items: [Item!]!
}
And a Hibernate entity (pseudo code):
#Entity
class Item {
#Id
private String id
#Column
private String name
#ManyToOne(fetch = FetchType.LAZY)
private: Person
...
}
The following query:
getAllItems {
id
name
}
And a hibernate query that loads just the items, would end up with first fetching all the Items in one query, and then fetching all the owners in a seperate query each (unless a owner is the same in multiple items, then its returned from the hibernate cache).
So my thought was that graphql-java recursively scans the objects that is returned to it, which causes the hibernate proxies to fetch.
Can i be right about this, or do you think my issue is completely unrelated to graphql-java?
UPDATE:
I found out that this has nothing to do with graphql, and is caused by hibernate. My relations are setup as LAZY, but Hibernate ignores this, and makes a query for each Person. So first a query that gets all Item's and next a query for each Person (n+1). And i do not access the proxies myself.
I create the query like this (this is kotlin):
entityManager
.createQuery("SELECT i FROM Item i", Item::class.java)
.setMaxResults(1000)
.resultList
To make things clear, this has nothing to do with GraphQL.
Hibernate eagerly loads one-to-one relationships by default.
To change this behaviour annotate the person field with
#OneToOne(fetch = FetchType.LAZY)
Given a Hibernate/JPA entity with cascading set to ALL for a related entity:
#Entity
public class Entity {
#OneToMany(cascade = CascadeType.ALL, orphanRemoval = true, mappedBy = "entity")
private Set<RelatedEntities> relatedEntities;
}
Is it possible to temporarily turn off the cascading, e.g. to allow Entity to be persisted without also persisting its relatedEntities?
No, it is not possible to do it, and at least according to my modest opinion, it would not be a good thing to do so either. When other developers look at the mappings and the code that does persist/merge/delete... they would expect the cascades to be applied and introduce the unexpected behavior if they oversee that the cascades are temporarily disabled somewhere else for the code they are about to change.
However, you can map to the same table a new entity class which does not have the fields that are cascaded. Then just use that entity in situations in which you don't want the cascades to be applied.
You can't temporarily disable cascading (to my knowledge, at least), but since you use Hibernate you can insert new entity using HQL
String hqlInsert = "insert into DelinquentAccount (id, name) select c.id, c.name from Customer c where ...";
int createdEntities = s.createQuery( hqlInsert ).executeUpdate();
There is always a "manual" solution where you remember relatedEntities in a variable for later use, and set null value as its value on Entity instance before persisting it.
I have a case where we have an inheritance strategy like this (this is an example of the jpa wiki, our real example is an other business case :))
#Entity
#Inheritance
#DiscriminatorColumn(name="PROJ_TYPE")
#Table(name="PROJECT")
public abstract class Project {
#Id
private long id;
...
}
#Entity
#DiscriminatorValue("L")
public class LargeProject extends Project {
#OneToMany
private Set<Member> members;
}
#Entity
#DiscriminatorValue("S")
public class SmallProject extends Project {
}
I have a bunch of projects in my database and want to fetch all the projects at once, but by doing this, i also want to fetch my list of members at once.
Is there a way to do this with jpql? I know the TYPE annotation allows me to look at the type, but can I combine this with a JOIN FETCH?
I'm using hibernate, but don't want to downgrade back to the hibernate api if I don't need to
JPA and Hibernate doesn't support fetching associations from subclasses, unless the property is also present in the topmost member of the hierarchy. But according to this post (https://thorben-janssen.com/fetch-association-of-subclass/) you can work around this limitation by exploiting hibernate's level 1 cache mechanism.
In you case you'll fetch all instances of Member first, in a separated query, and then perform your query on Project, letting LargeProject.members to be Lazy loaded. Instead of performing N + 1 SELECTs, hibernate will fetch those from the cache.
A bit late but I found a way by using only JPQL.
In your case :
SELECT p FROM Project p JOIN FETCH ((TREAT(p as LargeProject)).members)
I have 3 entities in a Hierarchy like this:
MyInterface
|
-----------------
| |
Entity1 Entity2
The MyInterface is NOT mapped in Hibernate (because I am using implicit polymorphism strategy to map this inheritance)
And, in fact, if I launch a query like this one:
"FROM MyInterface"
It works just fine (because it retrieves all the instances of Entity1 and all the instances of Entity2, puts them together, and returns a List<MyInterface>).
If we look at the SQL generated by Hibernate, it is launching 2 independent SQL queries to first retrieve the Entity1 instances an another one to retrieve Entity2 instances, but I am fine with this.
The BIG problem comes when you try to do something like this:
"FROM MyInterface ORDER BY someField"
Because it is applying the ORDER BY to the first SQL query and then the same ORDER BY to the second SQL query, instead of apply them to the WHOLE query (I know this because I can see the native SQL queries launched by Hibernate).
This is clearly a missbehaviour of Hibernate.
How can I work around this to force Hibernate to apply the ORDER BY to the whole query? (I cannot do it in memory because later I will have to add pagination also).
I'd say the problem is that Hibernate has to create those 2 SQL queries because you have to read from 2 tables.
I'm not sure if reading from 2 tables and ordering by 2 columns (one from each table) in one query is possible in plain SQL (means no vendor specific extensions), and if not, Hibernate would have to do the ordering in memory anyways.
What you could do when applying paging is: read the ids and the values you want to sort by only (not the entire entity), then sort in memory and read the entire entity for all ids contained in the page. For paging to be consistent you might have to store the results of that initial query (id + order criteria) anyways.
The way you are thinking cannot be mapped to SQL as is. Suppose you have Entity1 with fields field1A, field1B ... and Entity2 with fields field2A, field2B, ... Now you want the following query to be executed:
SELECT Entity1.* FROM Entity1
UNION
SELECT Entity2.* FROM Entity2
ORDER BY CommonField
which is not possible in SQL world, as entities have different number of fields and different field types.
So you need to think about extracting common fields into separate table CommonEntity, converting your interface into standalone entity with with one-to-one mapping to Entity1 & Entity2 (see Table per subclass). Then SQL will look like:
SELECT * from CommonEntity LEFT OUTER JOIN Entity1 ON Entity1.refId = CommonEntity.id LEFT OUTER JOIN Entity2 ON Entity2.refId = CommonEntity.id
ORDER BY CommonField
Or you can create a view over your tables and introduce an artificial discriminator (discriminator is something which will "distinguish" IDs from different tables, which caused a problem in your solution) and then map an entity to this view (so we get Table per class hierarchy):
CREATE VIEW EntityAandEntityB AS
SELECT 'A' as discriminator, Entity1.ID, CommonField1, ... CommonFieldZ, Entity1.field1A, ... Entity1.field1N, NULL, NULL, ... NULL(M)
FROM Entity1
UNION
SELECT 'B' as discriminator, Entity2.ID, CommonField1, ... CommonFieldZ, NULL, NULL, ... NULL(N), Entity2.field2A, ... Entity2.field2M
FROM Entity2
ORDER BY CommonField1, ...
Other alternatives (e.g. mentioned by #UdoFholl which is also kind of "outer join" for EntityAandEntityB) will result 2 SQLs and thus there is no way to order the "whole" query, and scrolling is not possible.
Hibernate will do this for you if you use the following.
#Entity
#Inheritance(strategy=InheritanceType.TABLE_PER_CLASS)
public abstract class AbstractEntity implements MyInterface {
private int someField;
}
Then have your subclasses that do this
#Entity
#Table(name="entity_1")
public class EntityOne extends AbstractEntity {
private int someOtherField;
}
#Entity
#Table(name="entity_2")
public class EntityTwo extends AbstractEntity {
private int anotherSomeOtherField;
}
You should then be able to write a query like this to get a single union SQL query with the DB doing the ordering.
FROM AbstractEntity ORDER BY someField