In previous releases, the MappingTool mapped java.math.BigDecimal fields to the database type DOUBLE, and as such, ignored column and precision values that might have been specified via the javax.persistence.Column annotation.

From the 2.3.0 release, java.math.BigDecimal fields are now mapped to the database type DECIMAL and it is very likely that you will need to specify column and precision via the javax.persistence.Column annotation.

In previous releases, the default value for the property RequiresSearchStringEscapeForLike is true and caused the unexpected escape clause appended to the SQL statement. For example, user created a named query like this:

 SELECT o.computerName FROM CompUser o WHERE o.name LIKE ?

At run time the following query is generated:

 SELECT t0.computerName FROM CompUser t0 WHERE (t0.name LIKE ? ESCAPE '\')

ESCAPE '\' shouldn't be appended to the query.

From the 2.3.0 release, RequiresSearchStringEscapeForLike property is set to false by default. You can configure RequiresSearchStringEscapeForLike property to be true if the old behavior is desired.

The JPA specification states "If SUM, AVG, MAX, or MIN is used, and there are no values to which the aggregate function can be applied, the result of the aggregate function is NULL." Prior to this update, OpenJPA incorrectly returned 0 for SUM, AVG, MIN, and MAX when a state field being aggregated is numeric. This behavior affects both JPQL and Criteria queries. With this update, OpenJPA will return a null result value for these aggregate functions when a query returns no result.

To re-enable the prior behavior, you need to set the following persistence property in your persistence.xml or when creating an EntityManagerFactory.

    <property name="openjpa.Compatibility" value="ReturnNullOnAggregateResult=false"/>