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: Persistence
Unit Testing of DB Schema and Named Queries
It is essential to software development, that bugs or misconfiguration are detected as early as possible. Therefore, tests being run during the build process can help to detect problems before your software is applied in a productive environment. In a EJB 3.0 application you may validate your DB-Schema and your named queries in a unit test, by starting up the EntityManagerFactory. It is one of the fine new features of JPA 1.0 (related to CMP in EJB 2.x) that you are able to use it without a container in a normal Java application. For your test you need a jndi.properties in your classpath:
Read More
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
Fetch strategy subselect for hibernate
The standard fetch strategy for collections in hibernate is lazy select fetching (hibernate performance). So if you retrieve some entities (for example via a query or a collection association) with a lazy collection association, subsequent calls to this lazy association will be retrieved one by one in further requests, for example. This is called the N+1-query problem, since there is one query for retrieving the entities itself and N additional queries for the lazy association. You can reduce the overhead by setting the hibernate.default_batch_fetch_size for your persistence unit in the persistence.xml. This reduces the problem to an N/batch_size +1-query problem. You can tell hibernate to use only 1+1-queries, if you set the fetch strategy to subselect fetching. This way, all entities in the association collections of the entities are retrieved in one query as soon as one of the associations is accessed. This will be helpfull only, if you do not pick one of the objects and retrieve the association, but iterate through your results and access the association of each of them. It is even contra productive otherwise. Read More
Problem using SQL keywords as field names in entities
If you’re using an JPA implementation in your application like hibernate you might try to name a field of an entity just as SQL keywords (e.g. ‘order’ or ‘key’). But beware of the nasty persistence provider.
Read More