Possibility to specify fetching of child entities is quite nice JPA feature. However, it was limited to either define the fetching as LAZY or EAGER. Fortunately, only prior to JPA 2.1.
As other programming components, data access layer has also its own patterns and anti-patterns. One of the most famous examples of anti-patterns is called select n+1.
Nowadays more and more applications are composed by several different data layers, beginning from the classical RDBMS and finishing in more adapted to some situations (search or graph relationships for example) NoSQL solutions. An interesting feature of JPA allows to notify no-JPA layer about some changes made on entities, exactly as in other solutions coming from event-driven development approach.
Until now in our examples we were using object inheritance based on entity classes (@Entity). However, we can also construct classes hierarchy without that, by using another JPA's annotation: @MappedSuperclass.
One of reasons-to-be of relational databases are relations. JPA provides very flexible way of manipulating them, through cascade attribute of annotations responsible for related objects (database tables).
JPA 2.0 brought some improvements for handling object collections. Before this release, to associate two objects, we were forced to define them as entities and use one from (One|Many)To(One|Many) mapping annotations. With 2.0 version came another possibility - @ElementCollection.
Querying database with JPQL queries is quite simple. But a main drawback of this solution is its static character. To create dynamic queries, a more adapted solution exists, JPA Criteria.
Entity modeling looks like the most important and the single meta data associated with a Java class in JPA. But it's not alone. Static metamodels are a meta data describing entity too. Unless, they are used in different purposes.
In the previous article about JPA we discovered how to create Java objects inheritance tree directly from a single database table with discriminator annotations. In this occasion we discovered also another interesting annotation, used to define inheritance type - @Inheritance.
Sometimes database data can be simply reflected in Java objects. But in other situations, when for example one database table stores several types of Java objects, it can be more difficult. And for these situations JPA uses discriminators.
Temporal information is very precious for all marketing purposes, as birthday e-mailing or several other reminders. JPA has specific annotation to handle this type - @Temporal.
In some situations @Entity annotation can be useless and we can still need to use Java objects as objects managed by JPA provider. In these cases we can use embeddable objects, representing by @Embedded and @Embeddable annotations.