Starting with Errai 2.1, Errai implements a subset of JPA 2.0. With Errai JPA, you can store and retrieve entity objects on the client side, in the browser's local storage. This allows the reuse of JPA-related code (both entity class definitions and procedural logic that uses the EntityManager) between client and server.
Errai JPA implements the following subset of JPA 2.0:
- Annotation-based configuration
- Entity Types with
- Identifiers of any numeric type (int, long, short, etc.)
- Generated identifiers
- Regular attributes of any JPA Basic type (Java primitive types, boxed primitives, enums, BigInteger, BigDecimal, String, Date, Time, and Timestamp)
- Singular and Plural (collection-valued) attributes of other entity types
- All association types (one-to-one, one-to-many, many-to-one, many-to-many)
- All association cascade rules (ALL, PERSIST, MERGE, REMOVE, REFRESH, DETACH)
- Circular and self references work properly
- Polymorphic queries and collections (queries for a base entity type can result in instances of its subtypes)
- Property access by field or get/set methods
- Identifiers of any numeric type (int, long, short, etc.)
- Named, typed JPQL queries that select exactly one entity type
- With cascading fetch of related entities
- With or without WHERE clause
- All boolean, arithmetic, and string operators supported
- All String manipulation functions supported
- With or without ORDER BY clause
- Lifecycle events and entity lifecycle listeners
- Much of the Metamodel API (Metamodel, EntityType, SingularAttribute, PluralAttribute, etc.)
|It's all client-side|
Errai JPA is a declarative, typesafe interface to the web browser's localStorage object. As such it is a client-side implementation of JPA. Objects are stored and fetched from the browser's local storage, not from the JPA provider on the server side.
To use Errai JPA, you must include it on the compile-time classpath. If you are using Maven for your build, add this dependency:
If you are not using Maven for dependency management, add errai-jpa-client-version.jar, Hibernate 4.1.1, and Google Guava for GWT 12.0 to your compile-time classpath.
Once you have Errai JPA on your classpath, ensure your application inherits the GWT module as well. Add this line to your application's *.gwt.xml file:
Errai ignores META-INF/persistence.xml for purposes of client-side JPA. Instead, Errai scans all Java packages that are part of your GWT modules for classes annotated with @Entity. This allows you the freedom of defining a persistence.xml that includes both shared entity classes that you use on the client and the server, plus server-only entities that are defined in a server-only package.
Classes whose instances can be stored and retrieved by JPA are called entities. To declare a class as a JPA entity, annotate it with @Entity.
JPA requires that entity classes conform to a set of rules. These are:
- The class must have an ID attribute
- The class must have a public or protected constructor that takes no arguments
- The class must be public and nonfinal
- No methods or persistent fields of the class may be final
- The class must be a top-level type (not a nested or inner class)
Here is an example of a valid entity class with an ID attribute (id) and a String-valued persistent attribute (name):
The state of fields and JavaBeans properties of entities are generally persisted with the entity instance. These persistent things are called attributes.
JPA Attributes are subdivided into two main types: singular and plural. Singular attributes are scalar types like Integer or String. Plural attributes are collection values, such as List<Integer> or Set<String>.
The values of singular attributes (and the elements of plural attributes) can be of any application-defined entity type or a JPA Basic type. The JPA basic types are all of the Java primitive types, all boxed primitives, enums, BigInteger, BigDecimal, String, Date (java.util.Date or java.sql.Date), Time, and Timestamp.
You can direct JPA to read and write your entity's attributes by direct field access or via JavaBeans property access methods (that is, "getters and setters"). Direct field access is the default. To request property access, annotate the class with @Access(AccessType.PROPERTY). If using direct field access, attribute-specific JPA annotations should be on the fields themselves; when using property access, the attribute-specific annotations should be on the getter method for that property.
Each entity class must have exactly one ID attribute. The value of this attribute together with the fully-qualified class name uniquely identifies an instance to the entity manager.
ID values can be assigned by the application, or they can be generated by the JPA entity manager. To declare a generated identifier, annotate the field with @GeneratedValue. To declare an application-assigned identifier, leave off the @GeneratedValue annotation.
Generated identifier fields must not be initialized or modified by application code. Application-assigned identifier fields must be initialized to a unique value before the entity is persisted by the entity manager, but must not be modified afterward.
By default, every field of a JPA basic type is a persistent attribute. If a basic type field should not be presistent, mark it with transient or annotate it with @Transient.
Single-valued attributes of entity types must be annotated with @OneToOne or @ManyToOne.
Single-valued types that are neither entity types nor JPA Basic types are not presently supported by Errai JPA. Such attributes must be marked transient.
Here is an example of an entity with single-valued basic attributes and a single-valued relation to another entity type:
Collection-valued types Collection<T>, Set<T>, and List<T> are supported. JPA rules require that all access to the collections are done through the collection interface method; never by specific methods on an implementation.
The element type of a collection attribute can be a JPA basic type or an entity type. If it is an entity type, the attribute must be annotated with @OneToMany or @ManyToMany.
Here is an example of an entity with two plural attributes:
When an entity changes state (more on this later), that state change can be cascaded automatically to related entity instances. By default, no state changes are cascaded to related entities. To request cascading of entity state changes, use the cascade attribute on any of the relationship quantifiers @OneToOne, @ManyToOne, @OneToMany, and @ManyToMany.
|PERSIST||Persist the related entity object(s) when this entity is persisted|
|MERGE||Merge the attributes of the related entity object(s) when this entity is merged|
|REMOVE||Remove the related entity object(s) from persistent storage when this one is removed|
|REFRESH||Not applicable in Errai JPA|
|DETACH||Detach the related entity object(s) from the entity manager when this object is detached|
|ALL||Equivalent to specifying all of the above|
For an example of specifying cascade rules, refer to the Artist example above. In that example, the cascade type on albums is ALL. When a particular Artist is persisted or removed, detached, etc., all of that artist's albums will also be persisted or removed, or detached correspondingly. However, the cascade rules for genres are different: we only specify PERSIST and MERGE. Because a Genre instance is reusable and potentially shared between many artists, we do not want to remove or detach these when one artist that references them is removed or detached. However, we still want the convenience of automatic cascading persistence in case we persist an Artist which references a new, unmanaged Genre.
The entity manager provides the means for storing, retrieving, removing, and otherwise affecting the lifecycle state of entity instances.
To obtain an instance of EntityManager on the client side, use Errai IoC (or CDI) to inject it into any client-side bean:
To store an entity object in persistent storage, pass that object to the EntityManager.persist() method. Once this is done, the entity instance transitions from the new state to the managed state.
If the entity references any related entities, these entities must be in the managed state already, or have cascade-on-persist enabled. If neither of these criteria are met, an IllegalStateException will be thrown.
See an example in the following section.
If you know the unique ID of an entity object, you can use the EntityManager.find() method to retrieve it from persistent storage. The object returned from the find() method will be in the managed state.
To remove a persistent managed entity, pass it to the EntityManager.remove() method. As the cascade rules specify, related entities will also be removed recursively.
Once an entity has been removed and the entity manager's state has been flushed, the entity object is unmanaged and back in the new state.
Errai's EntityManager class provides a removeAll() method which removes everything from the browser's persistent store for the domain of the current webpage.
This method is not part of the JPA standard, so you must down-cast your client-side EntityManager instance to ErraiEntityManager. Example:
For every entity instance in the managed state, changes to the attribute values of that entity are persisted to local storage whenever the entity manager is flushed. To prevent this automatic updating from happening, you can detach an entity from the entity manager. When an instance is detached, it is not deleted. All information about it remains in persistent storage. The next time that entity is retrieved, the entity manager will create a new and separate managed instance for it.
To detach one particular object along with all related objects whose cascade rules say so, call EntityManager.detach() and pass in that object.
To detach all objects from the entity manager at once, call EntityManager.detachAll().
To check if a given object is presently managed by the entity manager, call EntityManager.contains() and pass in the object of interest.
To retrieve one or more entities that match a set of criteria, Errai JPA allows the use of JPA named queries. Named queries are declared in annotations on entity classes.
Queries in JPA are written in the JPQL language. As of Errai 2.1, Errai JPA does not support all JPQL features. Most importantly, implicit and explicit joins in queries are not yet supported. Queries of the following form generally work:
Here is how to declare a JPQL query on an entity:
To declare more than one query on the same entity, wrap the @NamedQuery annotations in @NamedQueries like this:
To execute a named query, retrieve it by name and result type from the entity manager, set the values of its parameters (if any), and then call one of the execution methods getSingleResult() or getResultList().
To receive a notification when an entity instance transitions from one lifecycle state to another, use an entity lifecycle listener.
These annotations can be applied to methods in order to receive notifications at certain points in an entity's lifecycle. These events are delivered for direct operations initiated on the EntityManager as well as operations that happen due to cascade rules.
|@PrePersist||The entity is about to be persisted or merged into the entity manager.|
|@PostPersist||The entity has just been persisted or merged into the entity manager.|
|@PreUpdate||The entity's state is about to be captured into the browser's localStorage.|
|@PostUpdate||The entity's state has just been captured into the browser's localStorage.|
|@PreRemove||The entity is about to be removed from persistent storage.|
|@PostRemove||The entity has just been removed from persistent storage.|
|@PostLoad||The entity's state has just been retrieved from the browser's localStorage.|
JPA lifecycle event annotations can be placed on methods in the entity type itself, or on a method of any type with a public no-args constructor.
To receive lifecycle event notifications directly on the affected entity instance, create a no-args method on the entity class and annotate it with one or more of the lifecycle annotations in the above table.
For example, here is a variant of the Album class where instances receive notification right after they are loaded from persistent storage:
To receive lifecycle methods in a different class, declare a method that takes one parameter of the entity type and annotate it with the desired lifecycle annotations. Then name that class in the @EntityListeners annotation on the entity type.
The following example produces the same results as the previous example:
Errai captures structural information about entity types at compile time and makes them available in the GWT runtime environment. The JPA metamodel includes methods for enumerating all known entity types and enumerating the singular and plural attributes of those types. Errai extends the JPA 2.0 Metamodel by providing methods that can create new instances of entity classes, and read and write attribute values of existing entity instances.
As an example of what is possible, this functionality could be used to create a reusable UI widget that can present an editable table of any JPA entity type.
To access the JPA Metamodel, call the EntityManager.getMetamodel() method. For details on what can be done with the stock JPA metamodel, see the API's javadoc or consult the JPA specification.
Wherever you obtain an instance of SingularAttribute from the metamodel API, you can down-cast it to ErraiSingularAttribute. Likewise, you can down-cast any PluralAttribute to ErraiPluralAttribute.
In either case, you can read the value of an arbitrary attribute by calling ErraiAttribute.get() and passing in the entity instance. You can set any attribute's value by calling ErraiAttribute.set(), passing in the entity instance and the new value.
In addition to get() and set(), ErraiPluralAttribute also has the createEmptyCollection() method, which creates an empty collection of the correct interface type for the given attribute.
The following features are not yet implemented, but could conceivably be implemented in a future Errai JPA release:
- Flush modes other than immediate
- Transactions, including EntityManager.getTransaction()
- In named queries:
- Joins and nested attribute paths (a.b.c) do not yet work, although single-step attribute paths (a.b) do.
- The SELECT clause must specify exactly one entity type. Selection of individual attributes is not yet implemented.
- Embedded collections
- Compound identifiers (presently, only basic types are supported for entity IDs)
- EntityManager.refresh() to pick up changes made in localStorage from a different browser window/tab.
- Criteria Queries
- The generated static Metamodel
- The @PersistenceContext annotation currently has no effect in client-side code (use @Inject instead)
The following may never be implemented due to limitations and restrictions in the GWT client-side environment:
- EntityManager.createQuery(String, ...) (that is, unnamed queries) are impractical because JPQL queries are parsed at compile time, not in the browser.
- EntityManager.createNativeQuery(String, ...) don't make sense because the underlying database is just a hash table. It does not have a query language.
- Persistent attributes of type java.util.Calendar because the Calendar class is not in GWT's JRE emulation library.
We hope to remedy these shortcomings in a future release.
- In Dev Mode, changes to entity classes are not discovered on page refresh. You need to restart Dev Mode.
- The local data stored in the browser is not encrypted