Andres Delrotti wrote:I hope this would just be simple enough to convert. I'm just new to JPA, specifically JPQL and we wanted to convert this query.
Roel De Nijs wrote:
Andres Delrotti wrote:I hope this would just be simple enough to convert. I'm just new to JPA, specifically JPQL and we wanted to convert this query.
As you are new to JPA, you need a very good resource to refer to if you have doubts, questions and/or looking for some sample code (snippets). The Java Persistence API WikiBook is an excellent resource and when I'm having an issue with JPA, JPQL, or something related it's the first resource I'll check to find a solution. It's really awesome!
I would suggest having a look at several sections of this book: entity mappings, relationships, JPQL query,... and you'll probably discover yourself how this fairly simple query can be converted to JPQL.
Hope it helps!
Kind regards,
Roel
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:In JPQL you shouldn't be using JOIN at all.
The advantage of this (JOIN) operator is that the join can be expressed in terms of the association itself and the query engine will automatically supply the necessary join criteria when it generates the SQL.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:If you'll notice the difference between an explicit JPA JOIN and a native SQL JOIN, the native SQL goes like "SELECT x.*, y.* FROM x JOIN y ON x.abc = y.zzz" whereas in JPQL, all you need is "SELECT x FROM X JOIN ON Y", since the ORM already knows what the join columns are.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:As I said, I've an app that's (ab)used darn near anything JPA can do. Partly because the original data was pretty dirty.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:Actually, I'm using Hibernate JPA and that particular query was formulated about 3 years ago.
And it is still mentioned in the Hibernate 5.0 manual as well, so an alias in JOIN FETCH statements is definitely supported in Hibernate.Hibernate 3.3 Documentation, Associations and joins wrote:A fetch join does not usually need to assign an alias, because the associated objects should not be used in the where clause (or any other clause). The associated objects are also not returned directly in the query results. Instead, they may be accessed via the parent object. The only reason you might need an alias is if you are recursively join fetching a further collection
This tiny ad is suggesting that maybe she should go play in traffic.
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|