Listing 11.1. Finding an item by name using criteria queries
This method, from ItemManager , creates a criteria query using a meta-model and then
executes the query. Although verbose, the query will execute successfully at runtime be-
cause there are no strings that need to be dynamically evaluated. There's no chance that you
incorrectly used name instead of itemName . Now that you have a basic understanding of
criteria queries, let's dig into the meta-model API.
11.2.1. Meta-model API
The meta-model API provides a representation of the Java database entities as known by
JPA. In some ways it's very similar to Java's reflection APIs and the metadata API of
JDBC. As with reflection, you can iterate over the attributes of each entity and get basic in-
formation, including the name and the Java data type. You can also determine relationships
between entities such as whether there's a one-to-one relationship or a many-to-many, and
so on. In some ways this is similar to the DatabaseMetaData API provided by JDBC.
The API provided by JDBC provides low-level database schema information; the metadata
model provides information about JPA-managed classes. The meta-model API provides in-
trospection on the cached O/R mapping information.
The meta-model API is just part of the puzzle. To get static typing you need static objects
representing the data model. These objects are created using an annotation processor . An
annotation processor is a plug-in to the javac compiler that processes annotations at com-
pile time. In the case of JPA, it processes the annotations as well as the persisten-
ce.xml configuration. The meta-model processor generates Java source files for each
JPA-managed class. The generated source code files are ultimately compiled along with
the project to provide the static meta-model used at runtime. IDEs can introspect the meta-
model classes to provide code completion.