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
Author: jonny
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
OR-Mapper and the ‘many queries’ problem
Applications using an OR-Mapper like Hibernate or OpenJPA are reckoned as to be slow. This observation is true, since there is an overhead compared to using hand-crafted and optimized SQL-Queries and Database structure. But the overhead has not to be as big as it is often observed in applications with entities. There is a lot of potential optimizing such a system. Unfortunately you won’t be able to circumvent quarelling with the underlying database, although a persistence layer is all about abstraction. Not bringing into mind what happens in your persistence layer will lead to really bad performance. Read More
Unnecessary Code Detector
Recently I found a nice eclipse plugin for finding dead code. The standard eclipse check finds unused private fields and methods, only. You may use STRG+SHIFT+G for finding references to a public class or method in advance. But this approach is limited to search for methods/classes without references one by one, which is very time consuming. The UCDetector starts a search for methods and classses without any references to it in all projects in the current workspace respecting inheritance and presents the results in the ‘Problems’ view. 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
Interface with self-referencing generic type
The Comparable interface has a generic type parameter, which is used for self-referencing in subclasses (I don’t know any other use for it) :
public interface Comparable<E> {
public int compareTo(E other);
}
public class ComparableInteger implements Comparable<ComparableInteger> {
private int val;
public void compareTo(ComparableInteger other) {
return val > other ? 1 : (val == other ? 0 : -1);
}
But what if you need to access methods of the interface on the generic type parameter? Then you can do a recursive declaration of the type parameter. Read More
instanceof on Class objects
If you need to access the metadata of a class or be a bit less type safe than Java is by itself, you will have to get involved with the Java Reflection API. At that the question may arise, how to check whether one class object is the super class of another. If you are working with objects, you may use the java keyword instanceof. But this won’t work as expected for class objects, since all class objects are instances of Class<?> . So Class<?> owns the method cls1.isAssignableFrom(cls2), checking whether cls1 is a super class/interface or the same as cls2. So it works just like instanceof on objects, but the order of the parameters is switched.
Access javadoc programmatically
This tar ball (export-doclet-0.1.tar.gz) contains two maven project artifacts. It shows how to access the javadoc information of a project during the maven lifecycle phase ‘generate-sources’, traverse it, fill a Java object structure (export-doclet-api), marshal it to XML and include it into the jar of the artifact. Later on, you will be able to unmarshal the javadoc information. The export-doclet-api is oriented towards the doclet-api and the reflection-api and may therefore be familiar to you.
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