Accessing metadata at runtime

The JPA specification provides programming interfaces for accessing the metamodel of persistent classes. There are two flavors of the API. One is more dynamic in nature and similar to basic Java reflection. The second option is a static metamodel, typically produced by a Java 6 annotation processor. For both options, access is read-only; you can’t modify the metadata at runtime.

Hibernate also offers a native metamodel API that supports read and write access and much more detail about the ORM. We don’t cover this native API (found in org.hibernate.cfg.Configuration) in the book because it was already deprecated, and a replacement API wasn’t available at the time of writing. Please refer to the Hibernate documentation for the latest updates on this feature.

THEDYNAMIC METAMODEL API IN JAVA PERSISTENCE

Sometimes—for example, when you want to write some custom validation or generic UI code—you’d like to get programmatic access to the persistent attributes of an entity. You’d like to know what persistent classes and attributes your domain model has dynamically. The code in the next listing shows how to read metadata with Java Persistence interfaces.

Metamodel mm = entityManagerFactory.getMetamodel();

Set<ManagedType<?>> managedTypes = mm.getManagedTypes(); assertEquals(managedTypes.size(), 1);

ManagedType itemType = managedTypes.iterator().next(); assertEquals(

itemType.getPersistenceType(), Type.PersistenceType.ENTITY );

You can get the Metamodel from either the EntityManagerFactory, of which you typi- cally have only one instance in an application per data source, or, if it’s more conve- nient, from calling EntityManager#getMetamodel(). The set of managed types contains information about all persistent entities and embedded classes (which we’ll discuss in the next chapter). In this example, there’s only one: the Item entity. This is how you can dig deeper and find out more about each attribute.

Listing 3.10 Obtaining entity type information with the Metamodel API

SingularAttribute nameAttribute = itemType.getSingularAttribute("name"); assertEquals( nameAttribute.getJavaType(), String.class ); assertEquals( nameAttribute.getPersistentAttributeType(), Attribute.PersistentAttributeType.BASIC ); assertFalse( nameAttribute.isOptional() ); SingularAttribute auctionEndAttribute = itemType.getSingularAttribute("auctionEnd"); assertEquals( auctionEndAttribute.getJavaType(), Date.class ); assertFalse( auctionEndAttribute.isCollection() ); assertFalse( auctionEndAttribute.isAssociation() );

The attributes of the entity are accessed with a string: name

B and auctionEnd C.

This obviously isn’t type-safe, and if you change the names of the attributes, this code becomes broken and obsolete. The strings aren’t automatically included in the refac- toring operations of your IDE.

JPA also offers a static type-safe metamodel.

USINGASTATICMETAMODEL

Java (at least up to version 8) has no first-class support for properties. You can’t access the fields or accessor methods of a bean in a type-safe fashion—only by their names, using strings. This is particularly inconvenient with JPA criteria querying, a type-safe alternative to string-based query languages. Here’s an example:

CriteriaBuilder cb = entityManager.getCriteriaBuilder();

CriteriaQuery<Item> query = cb.createQuery(Item.class);

Root<Item> fromItem = query.from(Item.class); query.select(fromItem);

List<Item> items =

entityManager.createQuery(query) .getResultList();

assertEquals(items.size(), 2);

Listing 3.11 Obtaining entity attribute information with the Metamodel API

PATH: /examples/src/test/java/org/jpwh/test/simple/AccessJPAMetamodel.java Entity attribute

B

NOT NULL Entity attribute

C

This query is the equivalent of “select i from Item i.”

This query returns all items in the database; here there are two. If you now want to restrict this result and only return items with a particular name, you have to use a like expression, comparing the name attribute of each item with the pattern set in a parameter:

Path<String> namePath = fromItem.get("name"); query.where(

cb.like( namePath,

cb.parameter(String.class, "pattern") )

); items =

entityManager.createQuery(query)

.setParameter("pattern", "%some item%") .getResultList();

assertEquals(items.size(), 1);

assertEquals(items.iterator().next().getName(), "This is some item");

Notice how the namePath lookup requires the name string. This is where the type-safety of the criteria query breaks down. You can rename the Item entity class with your IDE’s refactoring tools, and the query will still work. But as soon as you touch the Item#name property, manual adjustments are necessary. Luckily, you’ll catch this when the test fails. A much better approach, safe for refactoring and detecting mismatches at com- pile-time and not runtime, is the type-safe static metamodel:

query.where( cb.like(

fromItem.get(Item_.name),

cb.parameter(String.class, "pattern") )

);

The special class here is Item_; note the underscore. This class is a metadata class and lists all the attributes of the Item entity class:

@javax.persistence.metamodel.StaticMetamodel(Item.class)

public abstract class Item_ {

public static volatile SingularAttribute<Item, Long> id; public static volatile SingularAttribute<Item, String> name; public static volatile SingularAttribute<Item, Date> auctionEnd; }

You can write this class by hand or, as intended by the designers of this API, have it automatically generated by the annotation processing tool (apt) of the Java compiler. The HibernateJPA2Metamodel Generator (a distinct subproject of the Hibernate suite) uses

“where i.name like :pattern” Has to be a Path<String> for like() operator!

Wildcards!

this extension point. Its only purpose is to generate static metamodel classes from your managed persistent classes. You can download its JAR file and integrate it with your IDE (or your Maven build, as in the example code for this book). It will run auto- matically whenever you compile (or modify, depending on the IDE) the Item entity class and generate the appropriate Item_ metadata class.

Although you’ve seen some mapping constructs in the previous sections, we haven’t introduced more sophisticated class and property mappings so far. You should now decide which mapping metadata strategy you’d like to use in your project—we recom- mend annotations, and XML only when necessary—and then read more about class and property mappings in the next chapter.

3.4

Summary

 You’ve implemented persistent classes free of any crosscutting concerns like logging, authorization, and transaction demarcation; your persistent classes only depend on JPA at compile time. Even persistence-related concerns should not leak into the domain model implementation.

 Transparent persistence is important if you want to execute and test your busi- ness objects independently and easily.

 You’ve learned the best practices and requirements for the POJO and JPA entity programming model, and what concepts they have in common with the old Jav- aBean specification.

 You’re ready to write more complex mappings, possibly with a combination of JDK annotations or JPA/Hibernate XML mapping files.

What is the annotation processing tool (apt)?

Java includes the command-line utility apt, or annotation processing tool, which finds and executes annotation processors based on annotations in source code. An anno- tation processor uses reflection APIs to process program annotations (JSR 175). The apt APIs provide a build-time, source file, and read-only view of programs to model the Java type system. Annotation processors may first produce new source code and files, which apt can then compile along with the original source.

Part 2

In document Java Persistence with Hibernate, 2nd Edition.pdf (Page 84-88)