Enterprise Java Development@TOPIC@

Chapter 73. JPA Criteria API

73.1. Criteria API Demo Template
73.2. Simple Entity Query
73.3. Non-Entity Query
73.4. Multi-select Query
73.4.1. Multi-select Query with Object[]
73.4.2. Multi-select Query with Tuple
73.4.3. Multi-select Query with Constructor
73.5. Path Expressions
73.5.1. Single Element Path Expressions
73.5.2. Collection Element Path Expressions
73.6. Eager Fetching through JOINs
73.6.1. Lazy Fetch Problem
73.6.2. Adding Eager Fetch during Query
73.7. Distinct Results
73.8. Summary


  • Get CriteriaBuilder from EntityManager

  • Build example-specific query definition in CriteriaQuery using CriteriaBuilder

  • Execute Query/Print results



  • "from"

    • defines source of root query terms

    • returns object leveraged in query body

  • "select" defines root query objects -- all path references must start from this set

  • no "where" clause indicates all entities are selected





  • Allows return of simple property

  • c.get("lastName") is called a "path"

  • All paths based from root query terms (thus requirement for Root<Customer> c object)

  • Single path selects return typed list of values


  • Query result is a List<String> because "c.lastName" is a String




  • Aliases may be assigned to select terms for named-access to results


  • Query defined to return instances of Tuple class

  • Tuples provide access using

    • get(index) - simular to Object[]

    • get(index, Class<T> resultType) - typed access by index

    • get(alias) - access by alias

    • get(alias, Class<T> resultType) - typed access by alias

    • getElements() - access thru collection interface




  • Individual elements of select() are matched up against class constructor


  • Constructed class may be simple POJO -- no need to be an entity

  • Instances are not managed

  • Suitable for use as Data Transfer Objects (DTOs)




  • All paths based off root-level FROM (or JOIN) terms

  • Paths use call chaining to change contexts

  • Paths -- used this way -- must always express a single element. Must use JOINs for paths involving collections

  • All paths based off root-level FROM (or JOIN) terms



  • Automatic INNER JOIN formed between Sale and Store because of the cross-entity path



  • A normal JOIN (implicit or explicit) may honor the fetch=LAZY property setting of the relation

  • Can be exactly what is desired

  • Can also cause problems or extra work if not desired


  • Sales are lazily fetched when obtaining Store


  • Accessing the Sale properties causes a LazyInitializationException when persistence context no longer active or accessible


One Row per Parent is Returned for fetch=LAZY

Note that only a single row is required to be returned from the database for a fetch=LAZY relation. Although it requires more queries to the database, it eliminates duplicate parent information for each child row and can eliminate the follow-on query all together when not accessed.



  • Limits output to unique value combinations