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: JPA
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
Ordering Collections with JPA
Often there is the need to sort an entity or a collection, e.g. If you have a list of line items in a bill and do not want that the order may change or is semantically wrong. Unfortunately, using a java.util.List will not suffice, since the DB has not to retain the order of the list. You might recognize this only after a long time, since some RDBMS will return the rows by insertion order. There are different ways to introduce an ordering with JPA (see Java Persistence: Ordering).
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
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
Multiple one phase resources in jBoss-5.1.0.GA
In jBoss-5.0.1.GA there was the configuration file ${JBOSS_HOME}/${SERVER_CONFIG}/conf/jbossjta-properties.xml. In order to enable distributed transactions for multiple local resources (non-XA) the following option had to be inserted into this file:
In jBoss-5.1.0.GA this config file has been replaced by ${JBOSS_HOME}/${SERVER_CONFIG}/conf/jbossts-properties.xml. So you have to add the same line into the xml-element with name properties and attributes depends with value “arjuna” and name with value “jta”:
<!-- ... -->