Using named queries has some nice advantages as described in Organize Your Named JPQL Queries. But it is not easy to convert queries to named queries as former are often programmatically created via string concatenation. At a first glance this seems to be a show stopper. In this post I will show two approaches to convert such queries into named queries.
Read More
Tag: JPQL
Organize Your Named JPQL Queries
Named queries have some nice properties. They are precompiled and therefore faster than their “normal” counterparts, encourage to use named parameters, make your code easier to read and avoid messing up your code with string concatenated queries. A nice addon is, that named queries are validated during the creation of the persistence unit. If you have a unit test (see unit test db schema and named queries), checking whether the entities represent a valid DB Schema, the named queries are validated, too. So, there will be syntactical as well as some static analysis (e.g. “exist all referenced entities?”) during the test phase, before your application is even packaged.
Read More
EAGER Fetch of Multiple Associations
Associations are fetched lazily by default. You may change this behavior by setting the parameter fetch=FetchType.EAGER of the annotation @OneToMany for example. This has the disadvantage, that the association is eagerly fetched each time the respective entity is retrieved from the underlying database. This leads to the so called cartesian product read issue since the respective association is retrieved with the query of the owning entity via LEFT OUTER JOIN (see JPQL and joins). So, a lot of redundant data might be retrieved from the database, since the OR-Mapper has no interception point where he can prevent to retrieve data cached already. Another way is to overwrite the lazy fetch type in a jpql query (see override fetch type). So the cartesian product read issue does still exist, but you can control when to eagerly fetch an assoctiation and when not.
Read More
JPQL joins and benefit/drawbacks of fetch joins
JPQL can handle LEFT OUTER JOIN (may be abbreviated to LEFT JOIN) and INNER JOIN (may be abbreviated to JOIN or to IN() <- don't use AS for the alias of "right hand side" here in combination with hibernate). The following document describes the different types of joins: visual explanation of sql joins.
Read More
Override fetch type in JPQL Queries
Executing a getter — representing a one-to-many or many-to-many association — on an entity causes one or n (with n entries in the collection) database calls, depending on the fetching strategy (see fetch strategies). This is a nasty little detail that may cause performance bottlenecks. Changing the fetch type (lazy/eager) may not be appropriate, since an association is generally used in more than one context, so there may be contradictory concerns. Generally spoken, an eager fetching is only in rare occasions a good idea on one-to-many or many-to-many associations, since this leads to the cartesian product problem (simply put, you have to read [nearly] the hole db in order to get one entity). Fortunately there is another solution that enables overriding a lazy fetch type in a dedicated JPQL-Query. This may entail a hole bunch of JPQL queries you will have to write (not more queries to execute on the db!!!), since you want to eagerly fetch an association in one situation but not in another.
Read More