[JPA_SPEC-111] Allow side-effect free check whether a named query is available Created: 21/May/15  Updated: 21/May/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Oliver Gierke Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently the only way to check whether a named query with a given name exists is calling EntityManager.createNamedQuery(…). Unfortunately the non-presence of a query is expressed by throwing an exception. That in turn causes a transaction currently in progress to be marked as to be rolled back:

Runtime exceptions thrown by the methods of the EntityManager interface other than the LockTimeoutException will cause the current transaction to be marked for rollback if the persistence context is joined to that transaction.

(from section 3.1.1. JPA 2.1 specification.

This means that even if the user code is able to mitigate this scenario, the currently running transaction will be broken. This has come up to be particularly problematic in the context of component systems that lazily instantiate application components (i.e. CDI) as this increases the probability of a business transaction already running when the EntityManager is created and used the first time.

Spring Data JPA currently tries to work around this by creating a dedicated EntityManager for the testing lookup. Also, in Spring environments application components are usually created eagerly so that it's less likely users run into these situations.

We introduced dedicated means to work around this in Spring Data but it seems to me that the fundamental issue – a plain lookup of something rolling back the transaction – is way too aggressive here.

If changing the behavior of EntityManager.createNamedQuery(…) is not an option, maybe providing a new method that allows to check for the presence of a named query could be an option to consider.






[JPA_SPEC-110] Lift requirement that MappedSuperclass, Entity and Embeddable classes must be top-level classes Created: 21/May/15  Updated: 21/May/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: flutter Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

all


Tags: embedded, entity, toplevel

 Description   

Currently, JPA Specification 2.1, section 2.1, paragraph 3, states:

> The entity class must be a top-level class

The section on @Embeddable classes, in turn, refers to that section.
It is my assumption that it would be quite safe also to allow static nested classes without posing too much problems to implementations.
So, I suggest to lift that requirement such that static nested classes are allowed as entities and/or embeddables.






[JPA_SPEC-107] Support subqueries in SELECT lists Created: 08/Apr/15  Updated: 08/Apr/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: dPiergies Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Whilst developing applications using JPA, we have repeatedly found ourselves in a situation where the restriction preventing subqueries from being used in SELECT lists poses a serious limitation, requiring us to work around the problem in one of several ways:

1. Rearrange the query to avoid using a subquery in the SELECT list. Not a problem, but not always possible (e.g. when a count of related entities is required).

2. Issue the subselect as separate queries. Not feasible in many situations as it requires an additional database query for every row returned by the original query. This can have a huge performance impact.

3. Denormalize our database schema so that the required data can be selected from a single table. This is acceptable in some circumstances, and indeed can boost performance for some operations, but in every instance we've come across the query containing the sub-select can be executed efficiently by the database, and it seems somewhat perverse to denormalize a database schema to work around limitations in the ORM API.

4. Resort to native queries. Not pretty. Breaks type safety and can easily lead to database portability issues. Makes problems such as limiting results for pagination and allowing variable sort orders far more complex to implement.

I really do hope that the next release of the JPA specification resolves this issue, as I believe that this restriction poses a serious limitation.






[JPA_SPEC-106] Clarify semantics of BindableType Created: 01/Apr/15  Updated: 01/Apr/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Oliver Gierke Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

BindableType has three values SINGULAR_ATTRIBUTE, PLURAL_ATTRIBUTE, ENTITY_TYPE.

For an entity like this:

class User {

  private User manager;
}

The lookup of the bindable type for the manager property returns ENTITY_TYPE on Hibernate and SINGULAR_ATTRIBUTE on EclipseLink. I'd argue the latter is wrong as the existence of ENTITY_TYPE indicates that it should be preferred over SINGULAR_ATTRIBUTE if the attribute indeed is a JPA entity. The spec however is completely silent on this and doesn't define any strict rules.






[JPA_SPEC-105] Allow AttributeConverter to be used for composite types by using @Embeddable Created: 26/Mar/15  Updated: 20/Apr/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Xavier Dury Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Right now, AttributeConverters can only be used for single-value types. They could be extended to use an @Embeddable type as a surrogate column type for composite types.

Imagine the immutable type Money(final BigDecimal amount, final Currency currency) and the following @Embeddable type:

@Embeddable
public class EmbeddableMoney {

	private BigDecimal amount;
	private Currency currency;

	// getters & setters
}

@Converter(autoApply = true)
public class MoneyConverter implements AttributeConverter<Money, EmbeddableMoney> {
	
	@Override
	public EmbeddableMoney convertToDatabaseColumn(Money attribute) {
		if (attribute == null) {
			return null;
		}
		EmbeddableMoney columns = new EmbeddableMoney();
		columns.setAmount(attribute.getAmount());
		columns.setCurrency(attribute.getCurrency());
		return columns;
	}

	@Override
	public Money convertToEntityAttribute(EmbeddableMoney dbData) {
		if (dbData == null) { // check if empty?
			return null;
		}
		return new Money(dbData.getAmount(), dbData.getCurrency());
	}
}

@Converter(autoApply = true)
public class CurrencyConverter implements AttributeConverter<Currency, String> {
	...
}

What do you think?



 Comments   
Comment by neilstockton [ 18/Apr/15 ]

Whilst this may cater for some types, it would do nothing for classes that the developer has no access to. If they wanted to map some type to 2 (or more) columns they couldn't.

What could be done is to take the existing AttributeConverter and use the second generic type (the column type) as Object[], so then the values of the column(s) can be obtained. An implementation would likely need to know the individual column types (since not obtainable from Object[]), hence add a new method

Class[] getDatabaseColumnTypes();

(or provide a new interface MultiColumnAttributeConverter (with this method above) that AttributeConverters implement should they want to persist to multiple columns).

Comment by Xavier Dury [ 20/Apr/15 ]

I don't understand how this could not be used for types the developer has no access to (as long as those types have a way to extract the necessary information to be persisted and there's a way to reconstruct objects based on that information, which btw is also needed when using Object[]).

In my example, EmbeddableMoney is used to (de)structure the Money type which is final and coming from an external library.

Another advantage of using an @Embeddable instead of Object[] is that you can annotate the properties with @Column and you can use those properties names in your query.





[JPA_SPEC-104] Enhance PersistenceUtil to allow initialization Created: 19/Mar/15  Updated: 19/Mar/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: paranoiabla Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hello,

at the moment the javax.persistence.PersistenceUtil provides methods to determine the load state of an entity. It would be also nice if we had methods to initialize and unproxy if the entity is a proxy object. I know Hibernate already have this in the org.hibernate.Hibernate class. It would be nice to have a pure JPA solution.



 Comments   
Comment by neilstockton [ 19/Mar/15 ]

Not all JPA implementations have such a concept as a "proxied object", and the majority don't require you to initialise anything. I can't see how this should become standardised ... its based on Hibernate's implementation only AFAIK





[JPA_SPEC-103] Lift input parameter restrictions Created: 18/Mar/15  Updated: 18/Mar/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: c.beikov Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I just came across JPA spec 4.6.4 and I was shocked. Is there any reason to limit input parameters to WHERE and HAVING clauses?






[JPA_SPEC-102] Add datetime functions Created: 28/Feb/15  Updated: 28/Feb/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: c.beikov Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There is currently no way to extract parts of a datetime attribute in a standardized way. Hibernate, EclipseLink and DataNucleus have support for that. I propose to add the functions:

  • YEAR
  • MONTH
  • DAY
  • HOUR
  • MINUTE
  • SECOND





[JPA_SPEC-99] Add ability to stream the result of a query execution Created: 21/Feb/15  Updated: 21/Feb/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Oliver Gierke Assignee: ldemichiel
Resolution: Unresolved Votes: 8
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Reading large datasets using JPA is quite uncomfortable these days as all method signatures return {{List}}s, which causes the entire result set to be pulled into memory before it can be handed to clients. Currently users work around this by paging through the results which sort of works but is error prone regarding inserts and deletes that might touch the same set of data to be read causing inconsistencies while iterating.

It would be great if alternatives to access a Stream (on JDK 8) or an AutoCloseableIterable (on JDK 7) could be provided to lazily iterate over a result set, e.g. EntityManager.stream(…) analog to the find(…) methods as well as Query.getResultStream().

It might be worth thinking about being able to hand an eviction policy to those methods to define rules to evict managed types from the EntityManager as otherwise the persistence context will inevitably grow during the streaming operation.



 Comments   
Comment by yeroc [ 21/Feb/15 ]

Duplicate of JPA_SPEC-89?





[JPA_SPEC-98] Improve Entity Graph annotations Created: 17/Dec/14  Updated: 17/Dec/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: radcortez Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Entity Graphs was a needed feature in the JPA spec and it's great to have them.

But, they seem to verbose when you have more than just the simple case. Look at this example:

https://github.com/javaee-samples/javaee7-samples/blob/master/jpa/entitygraph/src/main/java/org/javaee7/jpa/entitygraph/Movie.java

My suggestion would be to allows them to be used as Meta-Annotations, like I describe here:
http://www.radcortez.com/annotations-annotations-everywhere/

Or have a simplified form, where you could just do:

@NamedEntityGraph(
    attributes = {"id", "name", "description", "subgraph.property", "anotherSubgraph.property"}
)





[JPA_SPEC-97] Simplify referencing in JPA annotations Created: 16/Dec/14  Updated: 16/Dec/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: HajoLemcke Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Any



 Description   

The high fence to understand referencing in JPA and all the bugs in the implementing frameworks brought me to suggest a much easier approach:

Instead of all these @ManyToOne, @OneToMany, @OneToOne, @ManyToMany supported by additional (partially required) annotations like @JoinColumn and others I suggest just to map the database world into the Java world (which should be the goal of an OR-mapper anyway) by having only two annotations.

Referencing in the database world is achieved by one table having a column (or multiple) which references an entry in another (or even the same) table.

Why not just integrate this easy to understand subject into JPA?
Lets assume a database table named 'ParentTable' and a table named 'ChildTable' which has a column referencing 'ParentTable'.

The Java class named 'ParentClass' may have an object reference (or a collection) to 'ChildClass' which must be annotated with '@ReferencedBy( sourceEntity=ChildClass.class, sourceTable="ChildTable", sourceColumn="parentid" )'. If this is (currently) @OneToMany or @OneToOne is easily determined by the type of the property. If its a collection its @OneToMany.

The Java class named 'ChildClass' has the referencing column as a standard field like 'Long parentid = null;'. In addition it may have an object reference to its parent like 'ParentClass parent = null;' The new annotation here is '@References( targetEntity=ParentClass.class, targetTable="ParentTable", targetColumn="id" )'.

Additional parameters could be added to this two annotations like "nullable=", "onDelete=", "onUpdate=" ... which directly matches SQL.

Since there are two fields in 'ChildClass' (the column from the database table and the reference to the other class), setting them must follow some rules. But this is no more complicated than synchronizing a bidirectional relationship between two Java classes.

Example of setters in class 'ChildClass':
public void setParentid( Long parentid ) {
if ( parent != null && parent.getId() != parentid )

{ this.parent = null; }

this.parentid = parentid;
}

public void setParent( ParentClass parent ) {
this.parent = parent;
if ( parent != null ) {
this.parentid = parent.getId();
}}

This kind of setters could be ensured by bytecode manipulation, which is required in current framework implemantations anyway because the value of database column ChildTable.parentid must be stoerd somewhere.






[JPA_SPEC-96] Hint to prevent provider loading state beyond what graph specifies Created: 19/Nov/14  Updated: 19/Nov/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: arjan tijms Assignee: ldemichiel
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

JPA 2.1 introduced the concept of fetch graphs and load graphs. In a fetch graph attributes that are specified are treated as EAGER.

Unfortunately, there is no strong facility to specify which data should definitely NOT be loaded. Often limiting what should be loaded is even more important than specifying what should be loaded.

The functioning of fetch graphs is specifically hampered by the very unfortunate appearance of section 3.7.4 in the JPA 2.1 spec:

The persistence provider is permitted to fetch additional entity state beyond that specified by a fetch graph or load graph. It is required, however, that the persistence provider fetch all state specified by the fetch or load graph.

I would like to propose adding either an additional hint, to be used together with the fetch and load graph hints, or two new hints in addition to the fetch and load graph hints, that forbid the provider to load any additional state beyond that what is specified.

The definition of these new hints could be something like:

The persistence provider is strongly forbidden to fetch any additional entity state beyond that specified by a fetch graph or load graph. It is required that the persistence provider fetch all state specified by the fetch or load graph.






[JPA_SPEC-94] javadoc compilation prints out warnings on JDK8 Created: 12/Oct/14  Updated: 12/Oct/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Lukas Jungmann Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
clones JPA_SPEC-91 javadoc compilation fails on JDK8 Open

 Description   

javadoc generation fails on JDK8 mainly due to improper escaping of html entities and incorrect usage of closing tags

Javadoc tool output
...
  [javadoc] /Users/lukas/development/eclipselink/javax.persistence/src/javax/persistence/SqlResultSetMapping.java:36: error: bad use of '>'
  [javadoc]  *        "WHERE (order_quantity > 25) AND (order_item = i.id)",
  [javadoc]                                  ^
  [javadoc] /Users/lukas/development/eclipselink/javax.persistence/src/javax/persistence/spi/PersistenceProvider.java:81: error: reference not found
  [javadoc]      * @throws PersistenceException if insufficient or inconsistent
  [javadoc]        ^
  [javadoc] /Users/lukas/development/eclipselink/javax.persistence/src/javax/persistence/spi/PersistenceProvider.java:103: error: reference not found
  [javadoc]      * @throws PersistenceException if insufficient or inconsistent
  [javadoc]        ^
  [javadoc] /Users/lukas/development/eclipselink/javax.persistence/src/javax/persistence/spi/PersistenceProviderResolverHolder.java:41: error: unexpected end tag: </code>
  [javadoc]  * environment, the default </code>PersistenceProviderResolver is used.
  [javadoc]                             ^
  [javadoc] /Users/lukas/development/eclipselink/javax.persistence/src/javax/persistence/spi/PersistenceUnitInfo.java:35: error: element not closed: code
  [javadoc]      * <code>name</code> attribute in the <code>persistence.xml<code> file.
  [javadoc]                                                                ^
  [javadoc] /Users/lukas/development/eclipselink/javax.persistence/src/javax/persistence/spi/PersistenceUnitInfo.java:35: error: element not closed: code
  [javadoc]      * <code>name</code> attribute in the <code>persistence.xml<code> file.
  [javadoc]                                           ^
  [javadoc] 19 errors
  [javadoc] 100 warnings


 Comments   
Comment by Lukas Jungmann [ 12/Oct/14 ]

this is invalid, correct issue is JPA_SPEC-95





[JPA_SPEC-93] Convert example 9 incorrectly refers to 'name' instead of 'attributeName' Created: 08/Oct/14  Updated: 08/Oct/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Lukas Jungmann Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

see Example 9 at http://docs.oracle.com/javaee/7/api/javax/persistence/Convert.html






[JPA_SPEC-91] javadoc compilation fails on JDK8 Created: 23/Sep/14  Updated: 12/Oct/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Lukas Jungmann Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Cloners
is cloned by JPA_SPEC-94 javadoc compilation prints out warnin... Open

 Description   

javadoc generation fails on JDK8 mainly due to improper escaping of html entities and incorrect usage of closing tags

Javadoc tool output
...
  [javadoc] /Users/lukas/development/eclipselink/javax.persistence/src/javax/persistence/SqlResultSetMapping.java:36: error: bad use of '>'
  [javadoc]  *        "WHERE (order_quantity > 25) AND (order_item = i.id)",
  [javadoc]                                  ^
  [javadoc] /Users/lukas/development/eclipselink/javax.persistence/src/javax/persistence/spi/PersistenceProvider.java:81: error: reference not found
  [javadoc]      * @throws PersistenceException if insufficient or inconsistent
  [javadoc]        ^
  [javadoc] /Users/lukas/development/eclipselink/javax.persistence/src/javax/persistence/spi/PersistenceProvider.java:103: error: reference not found
  [javadoc]      * @throws PersistenceException if insufficient or inconsistent
  [javadoc]        ^
  [javadoc] /Users/lukas/development/eclipselink/javax.persistence/src/javax/persistence/spi/PersistenceProviderResolverHolder.java:41: error: unexpected end tag: </code>
  [javadoc]  * environment, the default </code>PersistenceProviderResolver is used.
  [javadoc]                             ^
  [javadoc] /Users/lukas/development/eclipselink/javax.persistence/src/javax/persistence/spi/PersistenceUnitInfo.java:35: error: element not closed: code
  [javadoc]      * <code>name</code> attribute in the <code>persistence.xml<code> file.
  [javadoc]                                                                ^
  [javadoc] /Users/lukas/development/eclipselink/javax.persistence/src/javax/persistence/spi/PersistenceUnitInfo.java:35: error: element not closed: code
  [javadoc]      * <code>name</code> attribute in the <code>persistence.xml<code> file.
  [javadoc]                                           ^
  [javadoc] 19 errors
  [javadoc] 100 warnings





[JPA_SPEC-90] Introduce row value constructor syntax Created: 13/Aug/14  Updated: 13/Aug/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: c.beikov Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

SQL-92 introduced the row value constructor and JPA should support it. Even though some databases do not support the syntax of SQL-92, it can be emulated as has been shown by JOOQ:

Hibernate even supports that syntax already as document here: https://docs.jboss.org/hibernate/orm/4.2/manual/en-US/html_single/#queryhql-tuple

The changes in the JPQL BNF would require to copy the following rules and giving the copies a suffix like '_1'.

  • arithmetic_primary
  • string_expression
  • boolean_expression
  • enum_expression
  • datetime_expression
  • entity_expression
  • entity_type_expression

Then transform the original rules like the following where R is the respecitve rule name

R ::= R_1 | { (R_1 {, R_1}*) }

Of course the naming is stupid but it allows this generic transformation description.

Null comparison and IN expressions follow the same scheme

null_comparison_expression ::=
	{null_comparison_expression_simple | {( null_comparison_expression_simple {, null_comparison_expression_simple}* )} } IS [NOT] NULL
null_comparison_expression_simple ::=
	{single_valued_path_expression | input_parameter}

in_expression ::=
	in_expression_lhs [NOT] IN
		{ ( in_item {, in_item}* ) | (subquery) | collection_valued_input_parameter }

in_expression_lhs ::=
	in_expression_lhs_simple | {( in_expression_lhs_simple {, in_expression_lhs_simple}* )} )
in_expression_lhs_simple ::=
	{state_valued_path_expression | type_discriminator}

in_item ::=
	in_item_simple | {( in_item_simple {, in_item_simple}* )} )
in_item_simple ::= literal | single_valued_input_parameter

And finally the subquery should also be able to have more than one select item.

simple_select_clause ::= SELECT [DISTINCT] simple_select_expression {, simple_select_expression}*





[JPA_SPEC-89] Introduce scroll as alternative to getResultList Created: 13/Aug/14  Updated: 13/Aug/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: c.beikov Assignee: ldemichiel
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Since Java 8 was much about streams, parallelism and so on, I guess it only makes sense to extends javax.persistence.Query to also offer a method, that returns something like hibernates org.hibernate.ScrollableResults.
Since Java 8 introduced Stream JPA could introduce something like a ResultStream that additionally supports scrolling.
This would make it possible to use JPA for big amounts of data






[JPA_SPEC-88] Pagination in JPQL and Criteria API Created: 13/Aug/14  Updated: 13/Aug/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: c.beikov Assignee: ldemichiel
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

JPA supports pagination but only on the outermost query. As described in the following article from JOOQ developers, it is possible to generate proper SQL for paginated subqueries.

http://blog.jooq.org/2014/06/09/stop-trying-to-emulate-sql-offset-pagination-with-your-in-house-db-framework/

I propose to add a pagination clause to JPQL and some methods to the Criteria API.

JPQL:

limit_clause ::= [LIMIT arithmetic_expression] [OFFSET arithmetic_expression]

Replace current statements with the following. Note that subquery now also needs to support orderby_clause and that limit_clause can only be used in conjunction with orderby_clause

select_statement ::= select_clause from_clause [where_clause] [groupby_clause] [having_clause] [(orderby_clause) | (orderby_clause limit_clause)]
subquery ::= simple_select_clause subquery_from_clause [where_clause] [groupby_clause] [having_clause] [(orderby_clause) | (orderby_clause limit_clause)]

Criteria API

javax/persistence/criteria/AbstractQuery.java
AbstractQuery<T> orderBy(java.util.List<Order> o) 
AbstractQuery<T> orderBy(Order... o) ;
AbstractQuery<T> limit(Expression<? extends Number> limit);
AbstractQuery<T> offset(Expression<? extends Number> offset);

and some covariant overrides for the subquery

javax/persistence/criteria/Subquery.java
Subquery<T> orderBy(java.util.List<Order> o) 
Subquery<T> orderBy(Order... o) ;


 Comments   
Comment by c.beikov [ 13/Aug/14 ]

Here a little example. If I want to paginate a query like the following

SELECT
    u
FROM
    User u
LEFT JOIN FETCH
    u.loginLogs
ORDER BY
    u.name

I can't use setFirstResult/setMaxResults on the query. So I have to use the following workaround

1. Fetch ids

SELECT
    u.id
FROM
    User u
ORDER BY
    u.name

2. Fetch entities

SELECT
    u
FROM
    User u
LEFT JOIN FETCH
    u.loginLogs
ORDER BY
    u.name
WHERE
    u.id IN :ids

Where the parameter ids will be set with the result of the first query.
Now if subqueries would allow some kind of LIMIT clause, I could turn that into a single query.

SELECT
    u
FROM
    User u
LEFT JOIN FETCH
    u.loginLogs
ORDER BY
    u.name
WHERE
    u.id IN (
	SELECT
		u.id
	FROM
		User u
	ORDER BY
		u.name
	LIMIT
		:maxResults
	OFFSET
		:firstResult
    )




[JPA_SPEC-87] Provide JPA equivalent to Hibernate Filters Created: 28/Jul/14  Updated: 13/Aug/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: paranoiabla Assignee: ldemichiel
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hello guys,

following this question:

http://stackoverflow.com/questions/19361166/jpa-equivalent-for-hibernate-filters

I would like to suggest that you include JPA equivalent to Hibernate's Filter. I'm using the filters of hibernate quite a lot and I think they are very helpful, so now i'm bound to use hibernate and I can't switch my JPA implementation.



 Comments   
Comment by c.beikov [ 13/Aug/14 ]

If Filters were added, it would be useful for libraries if we could add them before the EntityManagerFactory is constructed.
Also see JPA_SPEC-12





[JPA_SPEC-86] Allow multiple level @InheritanceType Created: 28/Jul/14  Updated: 28/Jul/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: paranoiabla Assignee: ldemichiel
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hello,

at the moment the spec says the annotation InheritanceType can be used only once - any subsequent uses are just ignored. My suggestion is to allow for multiple uses of this annotation.
For example let's say I have the following hierarchy:

AbstractEntity (with InheritanceType=TABLE_PER_CLASS)
 \--Product
 \--Widget (with InheritanceType=SINGLE_TABLE)
     \--Map
     \--Carousel
     \--Banner

I would expect Product and Widget to be in their own tables, but Map, Carousel and Banner to be all in the Widget table. However, currently this is not supported.






[JPA_SPEC-85] Add methods in Metamodel interface to get entity by jpa name Created: 28/Jul/14  Updated: 28/Jul/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: paranoiabla Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hello guys,

following this one:

https://www.java.net/forum/topic/glassfish/glassfish/how-obtain-class-j
pa-entity-name

and this one:

https://hibernate.atlassian.net/browse/HHH-9217

let's say I define an entity like this:

@Entity(name = "car")
public class Car {
}

now I want to get the EntityType by the name value (by "car").
Unfortunately this seems to be impossible I can get hold of the
EntityManager and from there I can get the Metamodel interface, but in
there I can see only one method which accept a class object:

<X> EntityType<X> entity(Class<X> cls);

I would like to propose several new methods to be included:

<X> EntityType<X> entity(String jpaEntityName);

<X> ManagedType<X> managedType(String jpaEntityName);

<X> EmbeddableType<X> embeddable(String jpaEntityName);

It seems quite logical to get the entity by the name it was given
(otherwise what' really the purpose of this name). And, yes, I know
about the solution where you get all the entities and iterate in a loop
and compare their names with the one you have, but I guess you would
agree this is a really poor performancewise. Another plus to this is
that the underlying implementation would be super-easy: just keep the
jpaEntityNames in a map (even for hibernate I have provided a 1-line
patch).

Please let me know what you think.

Thanks, and keep up the good work.






[JPA_SPEC-83] Require persistence providers to lazily register entity listeners as late as possible Created: 10/Jul/14  Updated: 10/Jul/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: smarlow Assignee: ldemichiel
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2014-01/message/3 didn't get much feedback but https://issues.jboss.org/browse/WFLY-2387 has gotten interest. The issue is that CDI injection allows you to inject the persistence context, and listeners support CDI injection. One way to resolve the cycle, is to ensure that persistence units always are available before the entity listeners are registered.

I suggest that we make it a requirement that entity listeners are not registered until the entity class is first used by the application (post application deployment time).






[JPA_SPEC-80] A standard way to obtain custom SQLSTATE issued by batches, triggers and stored procedures Created: 21/May/14  Updated: 21/May/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Rather any RDBMS is able to define custom SQLSTATEs. This becomes useful when writing batches, triggers and stored procedures, as the business logic inside that SQL programs has the ability to stop processing and inform the caller on business level exceptions (like "Account limit exceeded." encoded as SQLSTATE 'ATM13' when a user invokes "CALL ATM_withdraw(5000.00)" in a banking application). Sophisticated front ends (hence, calling applications) might want to differentiate between several custom SQLSTATEs (e. g. SQLSTATE 'ATM13' compared to 'ATM27' which might be a completely different business level reason to stop processing of the SQL program).

JDBC defines an unambiguous way to obtain these custom SQLSTATEs by SQLException.getSQLState(). Unfortunately, JPA does not but enforces product-specific workarounds. While some standard outcomes are provided as specialized PersistenceExceptions (e. g. EntityExistsException, EntityNotFoundException, etc.) there is no special exception for "custom causes". Also, it is not clearly said that EACH compliant entity manager MUST provide an SQLException containing the root cause to the PersistenceExceptions. While EclipseLink does provide this SQLException, it does not as a direct cause of PersistenceException. It seems to be even valid that compliant entity managers do not provide the causing SQLException at all.

As a solution I could imagine two alternatives:

(A) Define in the JPA spec that in case an entity manager is using JDBC to execute SQL statements, any thrown SQLExceptions MUST be returned DIRECTLY by PersistenceException.getCause().

(B) Define in the JPA spec that in case a database backend operation results in an unknown SQLSTATE, the returned PersistenceException MUST be an instance of the new class UnknownSQLState, and can be obtained by invoking UnknownSQLState.getSQLState().

While (A) is expected to be rather simple to implement by ORM vendors, in fact it is (B) which would provide the most unambiguous and simple solution to the application programmer.






[JPA_SPEC-79] EntityManager.createStoredFunctionQuery -- Using return values instead of result sets Created: 19/May/14  Updated: 19/May/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

JPA 2.1 provides a facility to call stored procedures, which greatly improves performance in many situations.

Unfortunately, it does not yet provide the same feature richess of JDBC. One partocular missing feature is the ability to read the result of a stored FUNCTION: The technical way to read those is defined by JDBC API, but not by JPA!

In JDBC, a return value can be simply queried by reading the OUT parameter at index 0, which is valid for all escaped functions when using the syntax {?=call myfunc(...)}. In JPA, providing a leading question mark leads to syntax errors. While using a native query using "SELECT myfunc(...)" certainly does work, it leads to unwanted performance overhead and code clutter, as it creates a CURSOR and wraps it using a JDBC ResultSet, possibly inducing additional network roundtrips to get that CURSOR's description and first row. JDBC prevents this by simply requesting the sole function result value as a side effect of the call, which is certainly available in the same roundtrip.

Hence, to spare overhead, improve performance and reduce application code size, it would be really great if JPA learns to deal with stored FUNCTION result values, just as JDBC can do it since many years.

A proposed syntax would be:

StoredFunctionQuery q = em.createStoredFunctionQuery("MyFunc(...)");
q.registerOutputParameter(0, Integer.class, OUT);
q.execute();
int = g.getParameter(0); <-- Returns value of '?=' in JDBC






[JPA_SPEC-78] TupleTransformer Created: 15/Apr/14  Updated: 13/Aug/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: c.beikov Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The constructor syntax in JPQL is limited by the fact, that the class must be visible to the classloader of the persistence provider. Also one might want to apply a custom transformation strategy based on metadata that does not use constructors but factories, builders or setters. To overcome these limitations I propose the addition of a TupleTransformer interface which can be implemented by a user to provide custom strategies.

TupleTransformer.java
public interface TupleTransformer<X> {
  List<X> transform(List<Tuple> tuples);
  X transform(Tuple tuple);
}

and an addition to Query and TypedQuery:

Query.java
public interface Query {
  // other methods
  Query setTupleTransformer(TupleTransformer<?> tupleTransformer);
}
TypedQuery.java
public interface TypedQuery<X> extends Query {
  // other methods
  <Y> TypedQuery<Y> setTupleTransformer(TupleTransformer<Y> tupleTransformer);
}

For reference see the ResultTransformer of Hibernate: http://docs.jboss.org/hibernate/orm/4.3/javadocs/org/hibernate/transform/ResultTransformer.html



 Comments   
Comment by c.beikov [ 13/Aug/14 ]

EclipseLink provides something similar(org.eclipse.persistence.queries.QueryRedirector) which can be used to do the same as with hibernate ResultTransformer.
If I understood it right, OpenJPA supports that with org.apache.openjpa.kernel.exps.AggregateListener, so every major JPA provider kind of already has that feature. Time to standardize





[JPA_SPEC-76] Allow specification for null handling in order-by expressions (JPQL and Criteria API) Created: 17/Mar/14  Updated: 13/Aug/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Oliver Gierke Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

§4.9 of the specification explictly states:

SQL rules for the ordering of null values apply: that is, all null values must appear before all non-null values in the ordering or all null values must appear after all non-null values in the ordering, but it is not specified which.

However, pretty much all of the important JPA providers support a nulls first/nulls last clause. So while it is already possible to define the strategy, it would be cool if one could reliably use it on top of JPA.



 Comments   
Comment by c.beikov [ 13/Aug/14 ]

Also not that this is important for database exchangeability. If I didn't specify nulls first or nulls last every query that uses the order by is non-portable between databases since databases have different defaults.





[JPA_SPEC-75] @Index.columnList should be an array Created: 11/Mar/14  Updated: 11/Mar/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: roxton Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In the JPA 2.1 specification, @Index has a String columnList property, and the specification presents this as a comma-delimited list. I propose that the specification be modified to make this property of type String[], both as a less surprising syntax and as an easier leap from Hibernate syntax.






[JPA_SPEC-74] Obtaining @Version value Created: 17/Feb/14  Updated: 17/Feb/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I want to suggest that a future release of the JPA API provides a means to get the value of an entities version attribute.

Example: em.getVersion(myEntity);
he
Justification: Generic frameworks like JAX-RS or Servlets might have an interest in getting the value of the version attribute without "knowing" which is "the version attribute" for any particular entity. For example, JAX-RS or Servlets want to send a ETag header to a client for any entity, but the Servlet does not "know" the class of that entity. Like when class name and primary key value are provided by a HTTP request. In that case, a solution would be em.getVersion(myEntity) which just should return the value of the version.



 Comments   
Comment by mkarg [ 17/Feb/14 ]

An improvement ontop would be em.isCached(Class<?>, id, version) which returns true or false, depending on the fact whether the EM has an entity with that primary key and version in cache.

Justification: To answer conditional HTTP requests it would be great to query the cache for a particular version. If the cache does not contain that version, EM shall NOT load from disk, but answer to JAX-RS or Servlet that this entity is not there.





[JPA_SPEC-73] Parameterized AttributeConverter and/or AttributeConverter metadata access Created: 07/Feb/14  Updated: 23/Dec/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: frenchc Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It would be good if we were able to parameterize AttributeConverter instances and/or have access to property metadata within an AttributeConverter. This way we are able to reuse AttributeConverter code instead of building similar ones or even supply further required context information. An example:

Quite often we have to deal with ancient DB schemas, and just recently we started to migrate a large Cobol application to Java. We are unable to change the content of the database, and because of Cobol with have to support fixed width string columns containing left padded data. A 5 digit fixed width column will represent 1 as '00001' and 100 as '00100'. Nothing we can change here. Unless I am mistaken I have to create a dedicated converter for every required fixed length ending up with an LeadingZeroTwoDigitAttributeConverter, LeadingZeroFiveDigitAttributeConverter and so on.

Right now it seems the JPA spec does not define wether there is one converter instance per persistent property or just a global one (which would be OK by current spec requirements). I would propose that parameterized converter instances are bound to property fields in order to support parameter evaluation during JPA provider startup.

I believe we need access to both basic attribute information and optionally supplied converter attributes. The following example would assume access to the leading pad char, the length attribute and wether the attribute is nullable or not. (in my current project I have to store an empty string for null values in the database).

@Convert(converter = LeadingDigitAttributeConverter.class, metaData="padChar=0" )
@Column(name = "ACOLUM", length=5, nullable = false)

If you believe there is no need to support something like that: Unfortunately we are in the middle of migrating quite a few very very old applications to Java, and we can't change that stuff. And there is more to come.



 Comments   
Comment by c.beikov [ 15/Apr/14 ]

I agree that metadata is needed but I guess it would be easier to just let the converter instance know about the metamodel Attribute instance or something simialar.
You can define your own annotations that can be used for configuration purposes of the converter. Through the metamodel you can get your hands on those values.
I propose that you can either inject that instance or with java 8 default methods around, introduce a new default method "void init(javax.persistence.metamodel.Attribute)" in the AttributeConverter.

Comment by frenchc [ 15/Apr/14 ]

Sounds good to me.

Comment by tomdcc [ 30/May/14 ]

We have need of this as well - we'd like to convert enum attributes to specific string representations in the database, and with the current spec we have to create a converter per enum, rather than e.g. having the enum classes implement an interface to make the required string available and use a single converter.

Hibernate has parameters that you can pass to their converter types which is a workaround for this, but we're not using Hibernate for this project and in any case it's pretty ugly to have to do that for every column.

Making the metamodel attribute available to the converter would be perfect, as it could then grab the attribute type. The nice thing about that approach, too, is that if someone wants to pass extra info in to the converter that isn't available in the normal JPA model, they can create a custom annotation and the converter can call attribute.getJavaMember() and look for annotations, and the info is right with all the other metadata for the attribute.

Comment by isk0001y [ 23/Dec/14 ]

Such a parameterized AttributeConverter may also be of help when one is creating converter for hundreds of enums.
In our project we have approx. 260 enums, which implement a simple interface.

I can use the AttributeConverter to persist any enum implementing that interface, by just calling "getFoo()"; assuming getFoo() will return a basic type like string, the direction to the database is problem-free.
However, since I cannot parameterize the Converter, and I have no access to the Property-Type in the entity the converter is about to be applied, I cannot reversely find out the Enum-Class whose foo i had persisted.
This end me in creating over 260 Converters alongside 260 enums.

Both eclipselink and hibernate provide have solutions for this. Eclipselink allows me to use their "Converter" infrastructure to create Converters with a special "initialize" method that allows me to access the entity property being converted. Hibernate allows me to create "UserDefinedTypes" like "UserType", where the @Type annotation takes an array of @Parameters to configure the converter. Both techniques result in me creating only ONE converter, but any entity class is then dependent on the concrete JPA provider through imports. This cannot be what you guys want

If I already must stick to one JPA provider, then I completely can skip using jpa at all, and stay incompatible.





[JPA_SPEC-72] Allow @PersistenceContext to be used on parameters ot enable constructor injection of EntityManagers Created: 07/Feb/14  Updated: 25/Mar/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Oliver Gierke Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently it's not possible to inject EntityManagers into constructors as @PersistenceContext is defined to not be allowed on parameters. it would be cool to enable this as users could then design application components using constructor injection only.



 Comments   
Comment by arjan tijms [ 25/Mar/14 ]

Wouldn't this automatically be possible when those contexts can be injected with @Inject?





[JPA_SPEC-71] Add subquery(EntityType) to javax.persistence.criteria.CriteriaQuery Created: 27/Jan/14  Updated: 27/Jan/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: koehn Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: entitytype, subquery

 Description   

If using dynamic entities not defined by classes (as is the case when using EntityMode.MAP), there's no way to create a subquery. This is because javax.persistence.criteria.CriteriaQuery.subquery() takes an entity Class as an argument, and unlike javax.persistence.criteria.CriteriaQuery.from() there's no overloaded method to subquery by EntityType. This severely limits what can be done using entities mapped with EntityType for which there is no Java class.






[JPA_SPEC-70] Allow two phase bootstrap approach to creating the EntityManagerFactory Created: 09/Jan/14  Updated: 09/Jan/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: smarlow Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Introduce a standard two phase persistence unit bootstrap and require that certain services are not accessed until the second phase. This will improve how JPA/CDI + JPA/@DataSourceDefinition work together.

In a perfect world, the first persistence unit bootstrap phase should not use the datasource or the CDI bean manager (instead wait for the second phase). Class enhancing/rewriting should also occur in the first phase (before application classes have been read).

This will help avoid use of the CDI bean manager too early (which otherwise can cause application entity classes to be loaded before they are enhanced/rewritten).

This will help avoid use of a datasource that is being deployed with the application (@DataSourceDefinition) but may not be available for use yet.

Also see discussion at https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2013-06/message/0.



 Comments   
Comment by arjan tijms [ 09/Jan/14 ]

+1!

This will also help or even be the solution for JAVAEE_SPEC-30

One question though; the two phases are thus needed for @DataSourceDefinition, but what about data sources that are defined in web.xml, ejb-jar.xml or application.xml.

Can't they be scanned and processed first without requiring the two phases?

Comment by smarlow [ 09/Jan/14 ]

One question though; the two phases are thus needed for @DataSourceDefinition, but what about data sources that are defined in web.xml, ejb-jar.xml or application.xml.

Data sources that are defined in web.xml, ebj-jar.xml or application.xml should also benefit by the change to bootstrap the persistence unit via two phases.

Can't they be scanned and processed first without requiring the two phases?

It will vary between application server implementations, when the data sources are available. On application servers that can start the data source earlier, supporting the two-phase pu bootstrap will also improve CDI injection in entity listeners (creating the bean manager will not prevent entity class enhancement).





[JPA_SPEC-69] Lift restriction limiting select clause to single-valued expression Created: 07/Jan/14  Updated: 01/Dec/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Section 4.8 of the JPA spec defines that a select expression is limited to a single-valued path expression.

Since there doesn't seem to be a clear reason for this restriction I would like to request to remove it. This will make it easier to e.g. construct a DTO from an entity where a collection attribute needs to be included.

See also: https://java.net/projects/jpa-spec/lists/users/archive/2014-01/message/0



 Comments   
Comment by c.beikov [ 13/Aug/14 ]

This is fixed in JPA 2.1 isn't it?

Comment by kithouna [ 01/Dec/14 ]

This is fixed in JPA 2.1 isn't it?

No, not fixed. Still open!





[JPA_SPEC-63] JPA next should support Java 8 Date and Time types Created: 11/Aug/13  Updated: 28/Mar/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nick Williams Assignee: Unassigned
Resolution: Unresolved Votes: 37
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: date, date-time, java8, jsr-310, temporal, time

 Description   

Currently, JPA temporal fields are supported for the following data types: java.util.Date, java.util.Calendar, java.sql.Date, java.sql.Time, and java.sql.Timestamp. java.sql.Date properties are always mapped to the JDBC methods getDate and setDate, and it is an error to specify the @javax.persistence.Temporal annotation for these types. The same is true of Time (mapped to getTIme and setTime) and Timestamp (mapped to getTimestamp and setTimestamp). Properties of type java.util.Date and Calendar must be annotated with @Temporal to specify the javax.persistence.TemporalType enum indicating which JDBC methods should be used for those properties.

Some vendors support other temporal types, such as Joda Time, but this is non-standard and should probably remain so since Joda Time isn't guaranteed to stay around (and, in fact, is likely to start ramping down with the release of Java 8).

JSR-310 as part of Java 8 specifies a new Date & Time API in the java.time package and sub-packages that supplants java.util.Date, Calendar, java.sql.Date, Time, Timestamp, and Joda Time. It is based off of the Joda Time API, but with enhancements and certain redesigns that the Joda Time founder/creator has said makes it superior to Joda Time.

JPA's existing rules for the currently-supported temporal types should remain largely unchanged. However, the specification should be added to in order to specify support for JSR-310. These are the proposed new rules I believe should be present in the JPA.next specification:

  • Properties of type java.time.Duration are treated as @javax.persistence.Basic fields. They automatically map to;
    • DURATION fields if the database vendor supports duration types;
    • DECIMAL-type fields storing the seconds before the decimal point and the nanoseconds after the decimal point;
    • INTEGER-type fields storing the seconds; and,
    • CHAR/VARCHAR-type fields storing the value in its ISO-8601 format (Duration#toString() and Duration#parse(CharSequence)).
  • Properties of type java.time.Period are treated as @Basic fields. They automatically map to:
    • PERIOD or DURATION fields if the database vendor supports period or duration types;
    • DECIMAL-type fields storing the seconds before the decimal point and the nanoseconds after the decimal point;
    • INTEGER-type fields storing the seconds; and,
    • CHAR/VARCHAR-type fields storing the value in its ISO-8601 format (Period#toString() and Period#parse(CharSequence)).
  • Properties of type java.time.Year are treated as @Basic fields. They automatically map to:
    • YEAR fields if the database vendor supports year types; and,
    • INTEGER/CHAR/VARCHAR-type fields storing the literal number/string value.
  • Properties of enum type java.time.Month are treated as special-case enum fields.
    • If the database field is a MONTH field (assuming the database vendor supports such types), it maps to this field.
    • If @javax.persistence.Enumerated is not present and the database field is an INTEGER-type field, it maps as the month number (NOT the ordinal) using int Month#getValue() and Month Month#of(int).
    • Otherwise, it falls back to standard enum mapping rules.
    • It is an error to annotate a Month property with @Enumerated if the database field is of type MONTH.
  • Properties of enum type java.time.DayOfWeek are treated as special-case enum fields.
    • If the database field is a DAY_OF_WEEK field (assuming the database vendor supports such types), it maps to this field.
    • If @Enumerated is not present and the database field is an INTEGER-type field, it maps as the day number (NOT the ordinal) using int DayOfWeek#getValue() and DayOfWeek DayOfWeek#of(int).
    • Otherwise, it falls back to standard enum mapping rules.
    • It is an error to annotate a DayOfWeek property with @Enumerated if the database field is of type DAY_OF_WEEK.
  • Properties of type java.time.YearMonth are treated as @Basic fields.
    • By default, they automatically map to:
      • YEARMONTH fields if the database vendor supports year-month types;
      • DATE and DATETIME fields storing the lowest day number that the database vendor supports and zero-time if applicable; and,
      • CHAR/VARCHAR-type fields storing the value in its ISO-8601 format (YearMonth#toString() and YearMonth#parse(CharSequence)).
    • The new @javax.persistence.YearMonthColumns annotation can map a YearMonth property to two database fields. A property annotated with this overrides the default mapping behavior. It is an error to mark properties of any other type with this annotation. The required @javax.persistence.Column-typed year attribute specifies the column that the year is stored in while the required @Column-typed month attribute specifies the column that the month is stored in. The year column follows the same default mapping rules as for Year types and the month column as for the Month enum. It is an error to specify @Column and @YearMonthColumns on the same property.
  • Properties of type java.time.MonthDay are treated as @Basic fields.
    • By default they automatically map to:
      • MONTHDAY fields if the database vendor supports month-day types;
      • DATE and DATETIME fields storing the lowest year number that the database vendor supports and zero-time if applicable; and,
      • CHAR/VARCHAR-type fields storing the value in its ISO-8601 format (MonthDay#toString() and MonthDay#parse(CharSequence).
    • The new @javax.persistence.MonthDayColumns annotation can map a MonthDay property to two database fields. A property annotated with this overrides the default mapping behavior. It is an error to mark properties of any other type with this annotation. The required @Column-typed month attribute specifies the column that the month is stored in while the required @Column-typed day attribute specifies the column that the day is stored in. The month column follows the same default mapping rules as for the Month enum and the day column automatically maps to INTEGER/CHAR/VARCHAR-type fields. It is an error to specify @Column and @MonthDayColumns on the same property.
  • Properties of type java.time.ZoneId are treated as @Basic fields. They automatically map to:
    • TIMEZONE fields if the database vendor supports time zone types (they never map to offset fields); and,
    • CHAR/VARCHAR-type fields storing the value in its ISO-8601 format (ZoneId#toString() and ZoneId#of(String)).
  • Properties of type java.time.ZoneOffset are treated as @Basic fields. They automatically map to:
    • OFFSET fields if the database vendor supports offset types (they never map to time zone fields); and,
    • CHAR/VARCHAR-type fields storing the value in its ISO-8601 format (ZoneOffset#toString() and ZoneOffset#of(String)).
  • Properties of types java.time.Instant, java.time.LocalDate, java.time.LocalTime, java.time.LocalDateTime, java.time.OffsetTime, java.time.OffsetDateTime, and java.time.ZonedDateTime are treated as temporal @Basic types that are mapped using the following rules:
    • LocalDate always maps as a date-only value. It is an error to mark a LocalDate property with the @Temporal annotation.
    • LocalTime and OffsetTime always map as time-only values. It is an error to mark a LocalTime or OffsetTime property with the @Temporal annotation.
    • Instant, LocalDateTime, OffsetDateTime, and ZonedDateTime map as timestamp values by default. You may mark a property of one of these types with @Temporal to specify a different strategy for persisting that property.
    • The new @javax.persistence.TemporalIncludeTimeZone annotation indicates that the offset in the OffsetTime or OffsetDateTime property or the time zone in the ZonedDateTime or Calendar property will be persisted with the value. Otherwise (if this is absent) the value is converted to the database server offset or time zone for persistence.
    • The new @javax.persistence.TemporalTimeZoneColumn(@Column value) annotation indicates a different column in which the time zone value is stored. It implies @TemporalIncludeTimeZone. It is required if @TemporalIncludeTimeZone is present but the database vendor does not support storing the time zone with the field data type. It is also required if @TemporalIncludeTimeZone is present but the JDBC driver in use is less than version 4.2 (a JDBC 4.2 driver is necessary to persist time zones and offsets with time/date-time values). The persistence rules for this column are the same as for ZoneId and ZoneOffset properties.
    • Properties of these types invoke the following special handling for JDBC driver versions before and after 4.2.
      • A JDBC driver is considered version 4.2 or better if java.sql.Driver#getMajorVersion() returns a number greater than 4, or it returns 4 and Driver#getMinorVersion() returns a number greater than 1. In the absence of a testable Driver instance, implementations may assume that the driver version is less than 4.2 if PreparedStatement#setObject(int, Object, SQLType) throws a SQLFeatureNotSupportedException.
      • If the JDBC driver is version 4.2 or newer, these seven types are persisted and retrieved as follows:
        • They are persisted with PreparedStatement#setObject(int, Object, SQLType) and retrieved with ResultSet#getObject(int, Class<?>) or ResultSet#getObject(String, Class<?>).
        • Time-only properties or TemporalType.TIME properties use a java.sql.SQLType of java.sql.JDBCType.TIME in the absence of @TemporalIncludeTimeZone or presence of @TemporalTimeZoneColumn. They use JDBCType.TIME_WITH_TIMEZONE in the presence of @TemporalIncludeTimeZone and absence of @TemporalTimeZoneColumn.
        • Date-only properties or TemporalType.DATE properties use a SQLType of JDBCType.DATE.
        • Date-and-time properties use a SQLType of JDBCType.TIMESTAMP in the absence of @TemporalIncludeTimeZone or presence of @TemporalTimeZoneColumn. They use JDBCType.TIMESTAMP_WITH_TIMEZONE in the presence of @TemporalIncludeTimeZone and absence of @TemporalTimeZoneColumn.
      • If the JDBC driver is version 4.1 or older, these seven types are persisted and retrieved as follows:
        • Time-only properties or TemporalType.TIME properties are automatically converted to and from Time and use the traditional setTime and getTime methods.
        • Date-only properties or TemporalType.DATE properties are automatically converted to and from java.sql.Date and use the traditional setDate and getDate methods.
        • Date-and-time properties are automatically converted to and from Timestamp and use the traditional setTimestamp and getTimestamp methods.
        • @TemporalTimeZoneColumn is required if @TemporalIncludeTimeZone is present.


 Comments   
Comment by Nick Williams [ 11/Aug/13 ]

To be clear, by "JPA.next" I mean JPA 2.2 unless 3.0 is next and there isn't going to be a 2.2. "Whatever is going to be in Java EE 8."

Comment by Nick Williams [ 11/Aug/13 ]

A few additional notes:

  • The reason for specifying the JDBC < 4.2 vs JDBC ≥ 4.2 behavior is that, even today, some JDBC driver vendors have still not fully implemented JDBC 4.0 (Java 6), let alone JDBC 4.1 (Java 7). Unfortunately and terribly, it could be 5 or even 10 years before all driver vendors have JDBC 4.2 drivers. Therefore, JPA vendors should support both mechanisms (since the JDBC 4.2 mechanisms allow saving with timezones, which JDBC 4.1 does not).
  • It is an error if the @TemporalIncludeTimeZone or @TemporalTimeZoneColumn annotations are present on properties of any type other than Calendar, OffsetTime, OffsetDateTime, and ZonedDateTime.
  • A Calendar, OffsetTime, OffsetDateTime, or ZonedDateTime must be converted from its time zone/offset to the database server's time zone/offset on persistence if and only if neither @TemporalIncludeTimeZone nor @TemporalTimeZoneColumn are present on the property. If either of those are present, time zone/offset conversion is not necessary because the time zone/offset will be saved with the time (either using setObject or a second column). Upon retrieval from the database, neither the date/time value nor the time zone/offset value should ever be altered. It should be accepted as it comes back from the database, whether stored together in the same column or separately in two columns.
Comment by Nick Williams [ 12/Aug/13 ]

Another note:

  • In addition to the int, Integer, short, Short, long, Long, and Timestamp types currently supported for @javax.persistence.Version-annotated properties, properties of type Instant may also be @Version-annotated.
Comment by mister__m [ 20/Feb/14 ]

YearMonth and MonthDay columns can also be mapped to INTEGER columns.

Comment by reza_rahman [ 25/Mar/14 ]

I must say this is an excellent initial analysis. For folks interested, the official Java Tutorial now has a nice trail on the Java SE 8 Date/Time API: http://docs.oracle.com/javase/tutorial/datetime/index.html. Details on JDBC 4.2 here: http://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/jdbc_42.html.

Comment by braghest [ 13/Apr/14 ]

Don't do ISO-8601 formatted CHAR/VARCHAR-type fields violate 1st normal form?

Comment by tomdcc [ 02/Jun/14 ]

Some databases such as Postgresql support storing time intervals [1], so the Duration and Period types should be allowed to map to such types if the underlying database supports them.

[1] http://www.postgresql.org/docs/9.3/static/datatype-datetime.html#DATATYPE-INTERVAL-INPUT

I believe that interval is an ANSI SQL standard type

Comment by perceptron8 [ 14/Jan/15 ]

Properties of type java.time.MonthDay are treated as @Basic fields.
By default they automatically map to:

  • ...
  • DATE and DATETIME fields storing the lowest year number that the database vendor supports and zero-time if applicable; and,
  • ...

This year must be also a leap year. Sadly, Date.valueOf(MonthDay.of(1, 1).atYear(0)) becomes "0001-01-01", so it can't be 0.

Comment by mkarg [ 26/Mar/15 ]

While I indeed support this feature request due to its common purpose, there actually is no real need for it anymore, thanks to the acceptance of the adapter API proposal filed by me in https://java.net/jira/browse/JPA_SPEC-35: You can just write a simple adapter that does the type conversion at runtime. Or are you aiming on schema creation instead of just type conversion?

Comment by ymajoros [ 27/Mar/15 ]

Yeah, but I think it would be a good idea to mention out-of-the box support in the spec, that providers can implement this way if they want. Otherwise, we'll end up basically having to package boiler-plate code every time we use java.time.* classes for JPA support.

Comment by mkarg [ 27/Mar/15 ]

While that is absolutely correct, the technical answer is a bit more complex: What is the final predicate that makes a data type eligible for inclusion in the set of mandatory type mappings?

One could say, that predicate is "being essential" or "being of common use", but who defines what "essential" or "common use" is? See, for some applications, support for java.awt.Image and java.net.URL might be much more essential than support for LocalDate or ZonedDateTime. On the other hand, other applications might be full of LocalDate but never uses Instant. So where exactly to make the cut? This becomes particularly complex when looking at the sheer amount of types found in the JRE, and it is obvious there has to be a cut somewhere. Even JavaFX, which is bundled with the JRE, does not support Instant still in v8, so why should JPA? And looking at the current progress of Project Jigsaw, possibly the qualifying predicate might simply be answered by "all types in a particular jigsaw module"?

Anyways, it is not up to me to decide. I do support your request, and would love to see support for rather all Java Time API times, particularly for Instant and Duration, and your request has prominent supporters like for example Java Champion Arun Gupa as I learned recently. But I doubt the final answer will be as simple an satisfying as we would love to have it.

Maybe it would be better to simply set up another JSR, like "Common Data Type Conversions for the Java Platform", which provides much more mappings than just date and time, but also would not be bound to JPA but also could be used by JAXB, JAX-RS, and possibly more API that deal which the problem of transforming "<A> to <B>"? Having such a vehicle would really reduce boilerplate a lot.

Comment by braghest [ 28/Mar/15 ]

there actually is no real need for it anymore, thanks to the acceptance of the adapter API proposal

I'm not sure. Firstly currently the RI explodes with a ClassCastException when trying to write an attribute converter mapping a java.util.Calendar database value. Secondly the spec would have to say that when mapping a java.util.Calendar the time zone of the value returned from the database is the time zone of the value on the database instead of the time zone of the Java virtual machine (like java.sql.Date). JDBC only allows to access the time zone of a value using the Java 8 Date and Time API.
If you currently want to access the timezone of a database value you need to use vendor specific extensions.





[JPA_SPEC-62] Standard name and value for "read-only" query hint Created: 22/Jun/13  Updated: 22/Jun/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Relational databases typically benefit from the knowledge, whether a transation will potentially modify and information (so locks are needed), or only read-only queries are executed (so no locks are needed). For similar reason, EclipseLink (and hopefully other JPA implementations, too) know query hints for "ready-only".

Unfortunately when using such vendor-specific hints, this will induce the problem that a portable application must know all these hints for all JPA implementations (or there will be no Performance gain for the unknown ones). This is not smart from the view of an ISV.

Hence I want to propose that the next maintenance release of the JPA specification defines a unique name and value to enable the read-only query mode independently of the actual JPA implementation.

Proposal: A compliant implementation which has a read-only query mode MUST enable this read-only query mode when the "javax.persistence.readonly" with a value of "true" is provided.






[JPA_SPEC-61] Retrieving primary key of lazy relationship Created: 18/Jun/13  Updated: 15/Apr/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JPA 2.0



 Description   

My server passes entities to clients as XML representations, simply by marshalling it using JAXB. This works well but there is one case where it fails: LAZY relationships. As I just want to include a URL for each reference (so clients can decide on their own whether to load this in turn), I need access to the primary key. But, as it is a LAZY reference, the attribute itself is NULL, and if I use the getter(), then the complete entity is instantiated – which I do not need and do not want. So it would be really great, if there would be solution, which makes JAXB and JPA work more closely. Like an API to get the primary keys of LAZY relationships, or even better, an automatic integration.



 Comments   
Comment by mkeith [ 18/Jun/13 ]

Markus,

With JPA 2.1 you could create an entity fetch graph for the related object and only load the PK. You would effectively have an unloaded object (except that it would have the PK) with its remaining state set to lazily load. There are some differences between this and having the whole object be lazily loaded since if the object ends up getting triggered then, depending upon the implementation, each of the attributes may end up getting loaded separately, but it could be configured to be fairly close I think. Of course, this would be a bit of a pain if you needed to do this for every lazy loaded attribute, but the advantage would be that it would also work pretty well for collection-oriented relationships.

-Mike

Comment by mkarg [ 19/Jun/13 ]

Unfortunately didn't find a tutorial on this on the web.

Currently I am doing this...

Foo f = em.find(Foo.class, myFooPK);
jaxbMarshaller.marshal(f);

...to get the root. Can you provide an example how to use that "fetch graph" thing to get the PKs of f's LAZY relations?

Thanks!
-Markus

Comment by mkeith [ 19/Jun/13 ]

From your first comment it sounded like you already had something (e.g. an XMLAdapter or some such thing?) on the relationship attribute to control marshalling a URL instead of the target Bar related object. Assuming that is the case (you need to stop the JAXB marshaller from continuing to traverse the Bar object) then you just need to access the PK of the Bar, right? If this is your usecase then you could do the following:

Define a named entity graph for Bar:
@Entity
public class Bar {
@Id long id;
public int getId()

{ return id; }


...
}

@XmlRootElement
@Entity
public class Foo

{ ... @XmlJavaTypeAdapter(MyBarToUrlAdapter.class) @OneToOne Bar bar; ... }

and then to read the Foo instance, you would do:

Map<String,Object> props = new HashMap<String,Object>();
props.put("javax.persistence.fetchgraph", em.createEntityGraph(Bar.class));
Foo f = em.find(Foo.class, myFooPK, props);
...

From within your adapter, or whatever you use to convert a Bar to a URL, you could get the id of the bar by calling getId() and the rest of the object will likely not be loaded (likely, because lazy does not imply not loaded). If this doesn't describe your problem then we can take this discussion offline.

Comment by arjan tijms [ 22/Jun/13 ]

It would be great if there was a way to just grab the PK of any entity, regardless of how it was loaded.

After all, we know the PK must be there as JPA uses it to lazy load the associated entity. It's just that the default mapping that we normally do with JPA doesn't give us access to this PK.

Maybe PersistenceUnitUtil would be an ideal place to put a utility method that can do this. It already contains functionality that's in the same category.

E.g.

Given

@Entity
public class Foo {

    @Id
    Long id;

    @OneToOne(fetch = LAZY)
    Bar bar;

    // + getters/setters
}

@Entity
public class Bar {

    @Id
    Long id;

    // + getters/setters
}

We could then grab the PK of Bar given an instance of Foo and an EntityManager em, as follows:

PersistenceUnitUtil persistenceUnitUtil = em.getEntityManagerFactory().getPersistenceUnitUtil();

Long barId;
if (persistenceUnitUtil.isLoaded(foo, "bar") {
    barId = foo.getBar().getId();
} else {
    barId = persistenceUnitUtil.getId(foo, "bar");
}

Note that the if/else is just for the example here. PersistenceUnitUtil#getId should be able to grab the Id of a given relation independent of its loaded status.

An alternative would be to explicitly map an extra instance field in Foo to the FK column in the table to which Foo is mapped, and then use a proprietary "read only" annotation, e.g.

@Entity
public class Foo {

    @Id
    Long id;

    @OneToOne(fetch = LAZY)
    Bar bar;

    @Column(name = "bar_id")
    @ReadOnly // made-up proprietary annotation, but many providers have something like this
    Long barId;

    // + getters/setters
}

I've seen this workaround actually being used in practice, but it's not so nice of course.

Comment by c.beikov [ 15/Apr/14 ]

@arjan: Which persistence provider are you using? In hibernate this is no problem and I also don't see why other persistence providers would load the entity just because you access the id. I don't know if the spec says anything about the behavior in that case but it would definitely be nice for portability reasons to have a defined behavior.





[JPA_SPEC-60] Upload official/standard JPA 2.1 API jar to Maven Central Created: 13/Jun/13  Updated: 07/Feb/14  Due: 22/May/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Matthew Adams Assignee: Unassigned
Resolution: Unresolved Votes: 24
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: maven, osgi, repositories

 Description   

There is no official or standard JPA API jar available from the expert group in either Maven Central or the java.net Maven repo that both JPA users & implementors can utilize. Users are left to search for implementations' groupId, artifactId, & version values, which is inconvenient.

Please upload a binary jar (including class files and relevant resource files), a source jar, and a javadoc jar, under the groupId "javax.persistence", artifact id "jpa-api" and version "2.1". A minimal target Maven repository would be Maven Central, but others like java.net might be nice, too.

Bonus points for including OSGi bundle metadata (pretty easy if using Apache Felix's Maven Bundle Plugin, org.apache.felix:maven-bundle-plugin:2.3.7)!



 Comments   
Comment by Matthew Adams [ 13/Jun/13 ]

This issue is the same as https://java.net/jira/browse/JPA_SPEC-19 except for JPA 2.1.

Comment by datanucleus [ 13/Jun/13 ]

Since when has an implementation had to provide their own variant of the "standard" API jar? Such a basic thing ought to be a prerequisite of the JSR to have that as one of its deliverables and the JSR not considered "complete" til its done, just like the spec and TCK (and add to that publishing of XSD/DTDs on a public site). Or maybe its just another way to keep it all "secret" (like that mystical TCK) ...

Comment by Matthew Adams [ 13/Jun/13 ]

http://search.maven.org/#artifactdetails%7Cjavax%7Cjavaee-api%7C7.0%7Cjar

Is this intended to be the release? If so, it might do for some, but a standalone JPA API artifact would be ideal.

Comment by neilstockton [ 14/Nov/13 ]

Seems like voting on this JIRA is not looked at by the people behind JPA, evidently not interested in what the majority of people want.

Comment by Oliver Gierke [ 07/Feb/14 ]

I'd also like to vote to finally introduce a canonical API JAR. We're currently seeing a lot of users running into classpath issues for the following reasons:

Persistence providers historically shipped their own packaged API versions. For libraries trying to build on top of JPA this created the unfortunate situation that they had to refer to a persistence provider provided API JAR which subverts the provider independence of the library.

Even worse, as the providers get access to the API JARs in different versions they do not use the specification version as artifact version but incorporate the spec version in the artifact id. E.g. for Hibernate, the API JAR has the following coordinates:

2.0 - org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.1.Final
2.1 - org.hibernate.javax.persistence:hibernate-jpa-2.1-api:1.0.0.Final

Note, that these two do not represent a single artifact in different versions but two completely separate artifacts. Hence, dependency management systems will not be able to apply version conflict resolution to those and users are very likely to accidentally get both JARs into their classpath and then spend a lot of time debugging ClassNotFoundExceptions for their JPA 2.1 provider that might see the 2.0 JAR first.

Long story short, this is way more tedious than it needs to be. Releasing a canonical API JAR would solve these issues.

P.S.: No, a 1.8 MB JavaEE 7 API JAR is probably not what you want to pull into an application or library that depends on JPA only.





[JPA_SPEC-58] script generation : same table name, different schema are merged Created: 15/May/13  Updated: 15/May/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: laps Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows : XP SP3
Glassfish : Oracle GlassFish Server 3.1.2.2 (build 5)
Eclipse : Indigo Build id: 20110615-0604
JRE : jdk1.6.0_33


Tags: create, ddl, eclipselink, generate, script, table

 Description   

Write two entities with the same table name but different schema :

@Entity
@Table(name="tablename", schema="schema1")
public class MyEntitySchema1 {
}

@Entity
@Table(name="tablename", schema="schema2")
public class MyEntitySchema2 {
}

Configure persistence.xml like this :
...
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<properties>
<property name="eclipselink.ddl-generation" value="create-tables"/>
<property name="eclipselink.ddl-generation.output-mode" value="sql-script"/>
<property name="eclipselink.create-ddl-jdbc-file-name" value="create.sql"/>
<property name="eclipselink.drop-ddl-jdbc-file-name" value="drop.sql"/>
...
</properties>
...

And then check the generated script create.sql :
CREATE TABLE schema2.tablename (...)
ALTER TABLE schema2.tablename ADD CONSTRAINT ...

Nothing about schema1.tablename in the script file.

If I change one thing (ex. update a letter of tablename from lowercase to uppercase, I get both tables generated. (Those tables already exist, so this is not a solution for me).






[JPA_SPEC-57] Support schema drop on restart Created: 11/May/13  Updated: 11/May/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: reza_rahman Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

javax.persistence.schema-generation.database.action=drop-and-create only drops the schema on undeploy/deploy. For rapid/agile/iterative development via IDEs, very frequently developers start and stop the app/server without necessarily triggering a deploy/undeploy cycle hence not performing a drop. In these scenarios, developers would want a schema drop to happen on app/server stop and start. Hibernate for example, supports this feature.

Such a feature could be supported via an additional property like javax.persistence.schema-generation.database.drop-on-restart=true, that is defaulted to false.



 Comments   
Comment by reza_rahman [ 11/May/13 ]

Do let me know if anything needs to be explained further - I am happy to help.

Please note that these are purely my personal views and certainly not of Oracle's as a company.

Comment by Mitesh Meswani [ 11/May/13 ]

javax.persistence.schema-generation.database.action=drop-and-create only drops the schema on deploy.

There might be scenarios where we might want to clean up database on undeploy. It would be nice to have an option where EMF.close() triggers a drop





[JPA_SPEC-56] @Convert annotation's converter property should be Class<? extends AttributeConverter>, not Class (unsafe) Created: 04/May/13  Updated: 17/May/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Nick Williams Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour


 Description   

Currently, the converter property for the @Convert annotation is declared as follows:

Class converter() default void.class;

However, along with just generally being unsafe ("safe" use would be Class<?>), this does not properly restrict the set of classes that can be specified. My understanding is that this MUST be a class that implements javax.persistence.AttributeConverter. Therefore, the converter property should be specified like so:

Class<? extends AttributeConverter> converter() default void.class;

With this change, the developer will know at compile time if he has specified an incorrect class. Without this change, the developer will not know until he gets a runtime error, which is seriously less desirable.



 Comments   
Comment by neilstockton [ 17/May/15 ]

You can't do that.

Class<? extends AttributeConverter> converter() default void.class;
would not compile. "void.class" is not castable to the generic form (but is to the non-generic form, hence probably why they did it).





[JPA_SPEC-55] Add variant of EntityManager#merge that modifies argument instead of returning new instance Created: 22/Apr/13  Updated: 14/Jan/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The EntityManager's persist method modifies its argument (the entity to be persisted) with generated data such as the Id.

The merge method can also be used to persist a new entity, but has the additional benefit that it can also update the entity or any of its relations in the DB. merge however does not modify its argument but returns a new instance in which the generated data such as the Id is set.

For some uses cases its needed to have the original entity instance be modified such as the persist method does, but with the semantics of the merge method.

For instance, in a JSF application an existing (persistent but detached) entity is passed into an action method to add a new entity into e.g. a @OneToMany relation. When the action method returns, rendering of the page begins, which still has a reference to the original entity. Depending on the backing bean and template structure of the page in question, it might not be trivial to have the action method replace this original reference that was passed into it, and the kind of update that persist does would be far more convenient.

For this I would like to request adding a variant of EntityManager#merge that modifies its argument instead of returning a new instance.

Alternatively a refresh method that accepts detached entities could also work for the above mentioned use case. Yet another alternative might be having an attach method that makes its argument attached, overwriting fields in that argument if an entity with the same identity happened to be present in the persistence context, but contrary to merge not updating any data in the database.



 Comments   
Comment by ymajoros [ 14/Jan/15 ]

What if you end up having multiple instances referring to the same row in database? They would all end up in PC??

If you do this in JSF, you really need to use the returned entity. If you can't do that, you have an architecture problem anyway.

persist() returns the same entity because it's new, and this guaranteed to be unique. You can't do that with updates.

Just curious: I don't really get your description of an attach() method that wouldn't update the database. Why would you want to have it managed by PC, but not updating the database? This is quite contrary to the basic ideas of JPA. Or am I missing something in your explanations?





[JPA_SPEC-54] Clarify behavior of RESOURCE_LOCAL EMF instantiated by container Created: 12/Apr/13  Updated: 12/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Mitesh Meswani Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It is possible to inject/lookup an EMF that is derived from a RESOURCE_LOCAL pu. For such EMFs, we need to clarify the behavior for following:

1. Should we disallow specifying jta-data-source

2. If the persistence.xml specifies both non-jta-datasource and javax.persistence.jdbc.* properties, which one should take precedence?

3. If the persitence.xml specifies no database connection information, should we default non-jta-datasource?

3. If the persistence.xml just specifies javax.persitsence.jdbc.* properties, what should be the behavior? Should we still default non-jta-datasource






Support for more automatic values besides @GeneratedId (JPA_SPEC-36)

[JPA_SPEC-51] @PrePersist / @PreUpdate / @PostPersist / @PostUpdate Created: 23/Feb/13  Updated: 23/Feb/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: mkarg Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

New annotations "@PrePersist" / "@PreUpdate" / "@PostPersists" / "@PostUpdate" annotations are used to define the event when the above annotations are to be injected.

@PrePersist will be the most typical use case.

Example:

@PrePersist @CurrentUser String createdBy; // Injects who created this record.
@PrePersist @CurrentTimestamp Date createdOn; // Injects when this record was created.
@PreUpdate @CurrentUser String lastUpdatedBy; // Injects who last updated this record.
@PreUpdate @CurrentTimestamp Date lastUpdatedOn; // Injects when this record was last updated.






Support for more automatic values besides @GeneratedId (JPA_SPEC-36)

[JPA_SPEC-50] @QuerySingleResult Created: 23/Feb/13  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: mkarg Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

New annotation "@QuerySingleResult(ejbql = "JPAQL QUERY" | namedQuery = "name of query")" should inject the .getSingleResult() output of either a given JPAQL query or of a named query into a field annotated with this annotation.

This is often needed in business applications, for example if the written data is dependend of a aggregate other entities. This is what a trigger would do in databases.



 Comments   
Comment by ldemichiel [ 05/Apr/13 ]

It seems more flexible to me to do this with a producer method.

Comment by mkarg [ 05/Apr/13 ]

While I agree that this solution is not the most flexible one, it possibly opens the most pragmatic solution, as it implies least code to write for the application developer (just one single line naming the query to invoke), offloads as much as possible to lower levers (as the query does all the work on the database server and just transports a single result value over the possibly slow line), and is rather intuitive as it mimics mosty the idea of an INSERT or UPDATE trigger which sets a single value by invoking an aggregating SELECT (like defaulting to the Count of existing rows etc.).

A producer method might be more flexible, but it is not so pragmatic in the daily use, as it implies much more code to write in turn for a flexibility that might not be needed (several lines of code), does not offload by default (depends on the cleverness of the developer, hence, does neither guide nor support him), and is not very intuitive (demands knowledge of a rather complex API instead of simple tagging a field and looking at the IDE's code completion proposals).

So my proposal would be to have both ways and let the developer decide. For daily use the annotation is best. For complex and seldom cases Producer methods are best. I do not see that it is a general, mutual-exclusive API decision, but a use-case driven API usage decision.





Support for more automatic values besides @GeneratedId (JPA_SPEC-36)

[JPA_SPEC-49] @CurrentTimestamp Created: 23/Feb/13  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: mkarg Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

New annotation "@CurrentTimestamp" should inject the current timestamp of a transaction into a data field.

The annotation will guarantee that at the transaction start the timestamp is produced once, so all uses of the annotation within the same transaction will guarantee to inject the same timestamp value.

This is another essential business need, as sometimes transactions run rather long, but all written data shall have synchronized timestamps.






Support for more automatic values besides @GeneratedId (JPA_SPEC-36)

[JPA_SPEC-48] @CurrentUser Created: 23/Feb/13  Updated: 22/Apr/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Sub-task Priority: Major
Reporter: mkarg Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

New annotation "@CurrentUser" should inject the current user into a data field (this is what databases do with the CURRENT USER constraint).

As in the Java EE environment there is a difference between security principals, business layer people, and database accounts, there should be a mapping available. For example "@CurrentUser(type = PRINCIPAL_NAME) String createdBy" would default the content of "createdBy" to the name of the caller principal's name. This is the most common need for automatic values in business applications.



 Comments   
Comment by arjan tijms [ 22/Apr/13 ]

I wonder if something akin to @CurrentUser should not also, or perhaps first, be available for the entire Java EE platform.

Comment by mkarg [ 22/Apr/14 ]

Arjan, you can inject the current security principal into any CDI beand and EJB. So you have that there already. My proposal is focused on JPA because you cannot inject the security principal into a JPA entity.





[JPA_SPEC-47] Usability of @Enumerated and @MapKeyEnumerated Created: 11/Feb/13  Updated: 28/Apr/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: jd3714att Assignee: ldemichiel
Resolution: Unresolved Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: enum, jpa

 Description   

In mapping a pre-existing schema, it is rarely possible to map a given set of constants using an @Enumerated:

  • Ordinals are non-sequential
  • Names are incompatible with Java Enum Constants
  • Names cannot be aliased to something more useful or conventional for Java Naming standards

Limitation is because specification states the name() will be used of an enum.
A typical example: Database uses 'N/A', which can never be mapped to an enum. Intuition will let us look for a solution to map this to 'NOT_AVAILABLE', both a valid name for an Enum Constant, and also conventional naming.

On top of this, an enum often has a representation in the Database, and a constant has usually other additional attributes that could be useful.
Better than using the name() of an @Enumerated, we should map the enumerated similar as an @Entity, and use the @ID.



 Comments   
Comment by jd3714att [ 26/Nov/14 ]

Would this not be more elegant than using a @Converter to solve the problem.

@Enumerated
public enum Language {
  ENGLISH_US("en-US"),
  ENGLISH_BRITISH("en-BR"),
  FRENCH("fr"),
  FRENCH_CANADIAN("fr-CA");
  @ID
  private String code;
  @Column(name="DESCRIPTION")
  private String description;

  Language(String code) {
    this.code = code;
  }
  
  public String getCode() {
    return code;
  }

  public String getDescription() {
    return description;
  }
}
Comment by HajoLemcke [ 16/Dec/14 ]

This looks great. And it would solve the problem to have a separate converter for each enumeration because a generic converter can not be build type save.

Comment by rbygrave [ 28/Apr/15 ]

I don't think @Column(name="DESCRIPTION") is required. The only requirement is to mark the field (as you have done with @ID) or mark a getter method that returns the value to be stored in the DB.

So instead annotate the getCode() method like:

@DbValue
public String getCode() { return code; }

or

@Id
public String getCode() { return code; }

Another alternative would be to create an annotation that acts just like @XmlEnumValue does for xml mapping ... so create a @DbEnumValue such that:

@Enumerated
public enum Language {
  @DbEnumValue("en-US")
  ENGLISH_US,
  
  @DbEnumValue("en-BR")
  ENGLISH_BRITISH,

  @DbEnumValue("fr")
  FRENCH,

  @DbEnumValue("fr-CA")
  FRENCH_CANADIAN;




[JPA_SPEC-46] Explicitly allow or disallow use of Entity Manager with extended Persistence Context for CDI injection Created: 05/Feb/13  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: donatasc Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

CDI specification has so called producer methods, allowing to create (or retrieve) objects to be injected.

JPA specification should explicitly state whether is it allowed for Stateful Session bean to have a producer method that returns extended EntityManager?
For example, is this legal:

@ConversationScoped
@Stateful
public class MyConversationBean {
@PersistenceContext(type=EXTENDED)
private EntityManager em;

@Produces
public EntityManager getEntityManager()

{ return em; }


}

This would be useful if conversation is implemented with several session beans and they all want to share a single extended EntityManager.



 Comments   
Comment by ldemichiel [ 22/Feb/13 ]

I think this is probably more an EJB issue than a JPA one, but in any case
it is something that we should evaluate for the next release.





[JPA_SPEC-43] Allow type level annotations to be used as meta-annotations Created: 17/Jan/13  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Oliver Gierke Assignee: ldemichiel
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: JavaEE, metatypes

 Description   

I repeatedly find myself annotating my JPA entities with the very same set of annotations:

@Entity
@EntityListeners(AuditingEntityListener.class)
class Person {

}

If both @Entity and @EntityListener were allowed to be used as meta-annotations I could collapse them into:

@Target(TYPE)
@Retention(RUNTIME)
@Entity
@EntityListeners(AuditingEntityListener.class)
@interface @AuditedEntity {

}

Resulting in:

@AuditedEntity
class Person {

}

This is in line with the meta-annotation handling CDI exposes to introduce annotation with richer semantics in annotation code. The following changes would be required.

  • Add ElementType.ANNOTATION_TYPE to the relevant annotations
  • Specify that persistence providers have to evaluate the annotations from the meta-level as well using the first one found, so that locally defined annotations would be considered first.


 Comments   
Comment by ldemichiel [ 18/Jan/13 ]

Support for this functionality is on our roadmap for Java EE 8. We should revisit this issue at that time.





[JPA_SPEC-41] @Target Declaration for @Embedded Created: 17/Dec/12  Updated: 11/Apr/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: mquasten Assignee: ldemichiel
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Using an @Embedded inside an entity or an other Embedded isn't posible using an Interface for the Declaration of the field.

@Entity(name="NaturalPerson")
public class NaturalPersonImpl implements NaturalPerson{

@Column(length=50)
private final String firstname;

@Column(length=50)
private final String lastname;

@Embedded
@Target(NativityImpl.class) // This annotation is a hibernate Annotation, not a JPA Annotation, it shoud be take over in JPA
private final Nativity nativity;

public NaturalPersonImpl(final String firstname, final String lastname, final Nativity nativity)

{ this.firstname=firstname; this.lastname=lastname this.nativity=nativity; }

...
}

...

entityManager.persist(new NaturalPersonImpl("Kylie", "Minogue", new NativityImpl("Melborne", new GregorianCalendar(1968, 4, 28).getTime( ) );

Instead of the @Target (as it is done in native Hibernate) something like @Embedded(target=NativityImpl.class) is posible too (as it is done for the normal Relations @OneToMany, @ManyToOne , @ManyToMany

HardCoding the Implementation is bad, because Mocking with Mockito, EasyMock and so on is limited, when the implementations use final for example. Using the Hibernate Annotations avoid exchange interchangeability of the persistence provider. Specifieng abstract Classes in the target definition may me not possible, because the type can not be resoved reading the values back from database (because it isn't defined like by entities where the implementation is stored in the database). But simple cases without polymorhism should be possible.



 Comments   
Comment by Paul Benedict [ 11/Apr/14 ]

I agree with the analysis that adding @Embedded(target=...) would be better than a new annotation. It aligns nicely with @Column(targetEntity=...)





[JPA_SPEC-39] Clarify requirements on polymorphic associations Created: 21/Sep/12  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: w_c_smith Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The 2.0 specification states in 2.9 that "Relationships are polymorphic", but there exists one case that appears to be completely valid JPA that Hibernate explicitly does not support. The specification should explicitly state whether a provider is required to support this case.

When using a joined or single-table inheritance strategy, it is a common occurrence that an entity (e.g., Order) has a ManyToOne relationship with another entity (e.g., Customer). Since JPA supports class inheritance, it is possible that some of the Order instances are actually instances of a subclass (SpecialOrder), and we might want to have a Collection of just the SpecialOrder s on the Customer entity. (This is especially likely if Order is abstract and we want relationships directly to the subclasses.) An example class hierarchy looks like this:

@Entity
public class Customer {
  @OneToMany(mappedBy = "customer")
  private Set<SpecialOrder> specialOrders;

  @OneToMany(mappedBy = "customer")
  private Set<RegularOrder> regularOrders;
}

@Entity
public abstract class AbstractOrder {
  @ManyToOne
  private Customer customer;
}

@Entity
public class SpecialOrder extends AbstractOrder {
  private Date shippingDate;
}

@Entity
public class RegularOrder extends AbstractOrder {
  private Integer storeNumber;
}

The specification appears to imply but does not explicitly state that this arrangement is valid, while Hibernate explicitly requires that the mappedBy property be physically present on the exact class specified in the relationship mapping, not inherited from a superclass. This mismatch has inspired a surprising number of "how-to-work-around" blog posts and should be explicitly resolved for the next version of the specification.






[JPA_SPEC-35] Support for more Java types Created: 06/Aug/12  Updated: 20/Mar/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: mkarg Assignee: ldemichiel
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

JPA currently only supports few Java types to be persisted, mostly generic types, Strings and Date. Since many applications would benefit from it, support for direct persistence of java.net.URL (as VARCHAR) and java.awt.Image (as BLOB) should be added. Both are commonly used in many applications and currently produce an overhead of manually written code when to be used in JPA entities.

In addition (or as a replacement for the above), it would be great to have the possibility to map any not supported Java type to any kind of supported Java type, in analogy to the XmlAdapters used in JAXB marshall / unmarshall. This would relax the need for special support for Image and URL. As an example how this could work, please look at the following pseudo-code, which demonstrates how java.net.URL could get marshalled to a String at time of persisting it:

@Column(name = "MY_SQL_FIELD_NAME"
@JpaAdapter(UrlJpaAdapter.class)
private URL someField;
...
public class UrlJpaAdapter.class extends JpaAdapter<String, URL> {
public URL unmarshal(String v) throws MalformedURLException

{ return new URL(v); }

public String marshal(URL v)

{ return v.toString(); }

}



 Comments   
Comment by sinuhepop [ 05/Nov/12 ]

I agree. This is a very common need and must be placed in JPA standard.

But I think it will be too verbose to put always the same annotation n the same types. Maybe is better to use a TypeRegistry:

TypeRegistry registry = entityManagerFactory.getTypeRegistry();
registry.register(URL.class, new UrlJpaAdapter());

Comment by neilstockton [ 20/Mar/15 ]

Alternatively, allow JPA implementations to support as many field types as they want to, and provide method(s) on ProviderUtil that returns the types that are supported, or whether a type is supported.

JPA could also just link in to the AttributeConverter facility, and a JPA implementation could find what converters are available in the CLASSPATH (and hence has support for them). Hence if a library provider wants their types automatically supported in all JPA implementations they just provide AttributeConverters ...





[JPA_SPEC-34] Add support for JSR303 (Bean validation) annotations. Created: 18/Jul/12  Updated: 15/Apr/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: velobr Assignee: ldemichiel
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: RFE

 Description   

Right now, JPA spec neglect Bean Validation annotations.

The way it is now we end with duplicated information:

    @Column(nullable = false, length = 200)
    @NotNull
    @Size(min = 4, max = 200)
    private String name;

Would be nice just do:

    @Column
    @NotNull
    @Size(min = 4, max = 200)
    private String name;

and end with same result.



 Comments   
Comment by ldemichiel [ 10/Dec/12 ]

Actually, result is not the same, because Bean Validation will trap the constraint validation before it goes to the database. I think what you may be asking for is integration of Bean Validation constraints into the schema generation facility. There has not been strong support for this, but it is something that we could consider in a future release.

Comment by c.beikov [ 15/Apr/14 ]

I think that this is also related to JPA_SPEC-23
If a "PhysicalCustomizer" as mentioned in the comments could alter the column definition we could even translate annotations to domain constraints by ourselves. I guess what we really need here is an abstraction that enables us to enrich the meta- and physical model in general.





[JPA_SPEC-32] Add a property to define cache implementation in persistence.xml Created: 27/May/12  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: c.beikov Assignee: ldemichiel
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: cache, configuration, jpa, persistence

 Description   

The cache implementation for the second level cache currently has to be configured via vendor specific properties but the semantics of the Cache are already reflected in the interface javax.persistence.Cache. The cache implementation should be configurable via persistence.xml.

I propose the property javax.persistence.cache.provider and the value of it should be the class name of the cache provider that actually implements javax.persistence.CacheProvider.

The CacheProvider interface could look similar to the RegionFactory interface hibernate actually uses.
Including the option to specify cache implementations in a stadardized way will improve the portability of applications and also make people to use the standard JPA provider of a container instead of packaging their own one in their applications.



 Comments   
Comment by arjan tijms [ 08/Nov/12 ]

Maybe it's also convenient to take JCache into account, instead of or perhaps next to a new javax.persistence.CacheProvider? Just like JPA 2.1, JCache is slated for inclusion into Java EE 7.

Comment by c.beikov [ 09/Nov/12 ]

I wasn't aware of the status of JCache back when I made this issue. Integrating JCache is IMHO the right way!





[JPA_SPEC-29] Constructing a CriteriaQuery from a Query Created: 24/May/12  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: ldemichiel
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: JPA_next, criteria, jpql, query

 Description   

In JPA 2 a query can be defined in JPQL for which a Query instance can be constructed, or via a Criteria for which a CriteriaQuery can be build. Via the EntityManager, a Query can be created from a CriteriaQuery.

However, it's not possible to create a CriteriaQuery from a Query. This would be particular useful for those use cases where a base query is written in the arguably more readable JPQL, which can then be transformed to a Criteria such that (small) modifications can be made to it programmatically. Such modifications could e.g. be adding an extra condition in an existing WHERE clause, adding an ORDER BY clause, etc.

I would like to request to add this capability.



 Comments   
Comment by ldemichiel [ 22/Feb/13 ]

Being able to map back and forth between CriteriaQueries and JPQL queries would be useful to have. This is something that should be considered in a future release.





[JPA_SPEC-25] Add support to retrieve JPQL query from Query object Created: 24/May/12  Updated: 25/Jun/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: c.beikov Assignee: ldemichiel
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: JPA_next, jpql, query

 Description   

Currently the interfaces javax.persistence.criteria.AbstractQuery and javax.persistence.Query have no support for retrieving the underlying JPQL Query for additional transformation which would be, especially for named queries, very useful! Just think of the fact, that you currently have to copy and paste a named query if you like to have exactly the same query with an additional predicate in the where clause. The predicate in the where clause is just an example, there are probably tons of use cases where this feature would be helpful and minimize redundant code!

I would suggest to add the following methods:

Query.java
public interface Query{
  // currently available methods...

  public String getQuery();
}
AbstractQuery.java
public interface AbstractQuery{
  // currently available methods...

  public String getQuery();
}


 Comments   
Comment by Antonio Goncalves [ 25/May/12 ]

As I wrote on my blog (http://agoncal.wordpress.com/2012/05/24/how-to-get-the-jpqlsql-string-from-a-criteriaquery-in-jpa/), having the JPQL String representation of a CriteriaQuery is very useful for debugging purpose. And going further, having the SQL String would also be useful. I would go for :

public interface Query {

  public String getJPQLQuery();
  public String getSQLQuery();

}
Comment by ldemichiel [ 22/Feb/13 ]

Being able to map back and forth between CriteriaQueries and JPQL queries would be useful to have. This is something that should be considered in a future release. See also http://java.net/jira/browse/JPA_SPEC-29

Comment by arjan tijms [ 22/Jun/15 ]

Just wondering if this is still considered, specifically for Java EE 8 (for which no JPA EG has been formed as of now).

In the 3 years since this issue has been created the lack of this feature impedes my work on almost a daily basis. In particular it makes paging/sorting from services quite difficult and obscure.

Comment by neilstockton [ 24/Jun/15 ]

+1 but I would suggest that the method to return the (SQL) native query is actually

String getNativeQuery();

which then aligns with how "SQL" is accessible in the query API.

Comment by arjan tijms [ 25/Jun/15 ]

I wrote an article about this issue and described how to do this when using Hibernate. See http://jdevelopment.nl/counting-rows-returned-jpa-query

Ideally something like would be standardized. Note that just String getNativeQuery() is not really enough. Some info about the translated query parameters is also needed.





[JPA_SPEC-21] enable Serialisation of Entities Created: 10/May/12  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Mark Struberg Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: JPA_next

 Description   

Currently a JPA provider cannot guarantee that Entities are serializable since it is always possible that the entity is pessimistically locked (select for update).

The other problem is that JPA entities (per spec) loose all the state of lazy loaded fields and their dirty tracking information on serialisation. The result is that you basically cannot use them for any web application. Even if most EE6 samples use entities directly in their backing beans this does not work in practice (if you do not use non-spec conform magic switches) if clustering kicks in or you use e.g. the JSF ViewMap to store your entities.

The JPA spec currently states that you can either use lazy loading or serialisation. But this is impracticable. Not being Serializable means that you cannot use Entities in a webapp. Not having LazyLoading means that you will end up with 'database spaghetti' (pulling one entity and materializing half the database).

A possible solution:

step A:

/**
 * This one only allows optimistic operations and will throw an Exception on pessimistic ones.
 * It can be created via EntityManagerFactory#createOptimisticEntityManager()
 */
public interface OptimisticEntityManager extends EntityManager, Serializable {}

step B:

force that each @Entity produced via this OptimisticEntityManager must explicitly declare the following fields:

  • @Id and @Version. Otherwise you cannot do optimistic locking properly after serialisation.
  • a state field [1] to serialize all information needed to track dirty fields and lazy loading information even after serialisation.

[1] I'm not yet sure how to implement this best. OpenJPA and EclipseLink already store all the state in the enriched/enhanced/weaved entity. The problem is just that they need to be switched to a mode where they do not only serialize the native entity but also all additionally needed info as well.
Since Hibernate stores all this information in the EntityManager (and not in the Entity), we need to spare some field in the Entity which will get filled when the entity gets detached.

One way would be to introduce a new field of type javax.persistence.State which must always be available in Serializable entities used by an OptimisticEntityManager. Of course this field never gets persisted to the db.

Any other ideas and spec clarifications (if I misunderstood something) is highly welcome!



 Comments   
Comment by mkeith [ 15/May/12 ]

We have actually spent a great of time discussing variants of this problem since the first release of JPA, and there are a few possible solutions to the problem, but because of differing vendor opinions, implementations, and philosophies we have not yet reached a satisfactory conclusion. Unfortunately it is doubtful we will be able to do so in this release, either.

Comment by Mark Struberg [ 20/May/12 ]

Hi Mike!

Thanks for the honest answer. As I am EG member on other JSR myself, I certainly know those 'games'. This special issue has indeed a long history. I've seen EJB bug reports from 2005 (or even older?) which are originated in this very problem. And they all got bulk-updated and set to closed WITHOUT solving the underlying problem.

But all this doesn't change the fact that this is still broken and users don't care about political games behind the scene. This is really one of the reasons why user turn away from JPA and use SpringData, iBatis and eBean instead.

Currently the only way you can work with JPA in big projects is the old EJB transaction pattern where all entities get detached after the service invocation and NOT get used anymore in JSF pages or even JSF backing beans. But exactly that is what most EE6 samples currently showcase - despite being broken. This also renders JSR-303 mostly useless. Really, the only way to use JPA in a web app atm is to only use DAOs in the view layer and doing optimistic locking detects manually. This just sucks.

As for the JPA vendors:
I'm pretty sure that JBoss is interested to fix this. Especially since they heavily promote the entitymanager-per-conversation pattern which would then start to work.
I'm OpenJPA committer myself, and I think this will also be welcome in our community.
I've not much clue about EclipseLink, but as they afaik also store the state inside the Entities it should also be doable.

Are there any other JPA vendors which are active in the JSR or have a bigger community?

Comment by ldemichiel [ 22/Feb/13 ]

Well, we tried to resolve this via a proposal based on entity graphs, but could not achieve closure. This is something that we should revisit in JPA.next.





[JPA_SPEC-17] Dynamic persistence unit Created: 01/Apr/12  Updated: 11/Nov/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: likenootherufo Assignee: ldemichiel
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: JavaEE, dynamicaly, persistence

 Description   

Without changing code and redeploying my application, I need to be able to switch persistence units in some of my EJBs based on client connected to system.
It is similar to multitenancy, but whereas there a single DB is divided into equal shares and shared between multiple tenants, here a single tenant wants multiple DBs appearing as a single one.
During runtime based on the client connected to the EJB, the specific database should be selected.
Currently I achieve this using JDBC connections and just changing the database connection details based on client connected.
The database connection details are stored in the main system database and retrieved when the client connects.
This allows the system to grow with ease as new client databases can be created on the fly and simply linked to the client
in the database.
Ideally I would like to dynamically add new persistence units to the system (persistence.xml) and then in my database
link these persistence units to a given client. When the client connects, the system loads the required persistence unit.



 Comments   
Comment by ldemichiel [ 22/Feb/13 ]

I think you are really asking for multitenancy support in Java EE, which is something that we don't yet support. This is a candidate item for Java EE 8, at which point we should revisit this issue for JPA.

Comment by c.beikov [ 24/Apr/13 ]

This would be something really nice to have but I also think that this is already possible.
You coud have e.g. a CDI producer for the EntityManager which returns a proxy that is actually capable of that switching.
This is really nice, I think I will implement this in my application too

public class EnvironmentAwareEntityManager implements EntityManager {

  @Inject
  @Any
  private Instance<EntityManager> ems;

  private EntityManager select(){
    for(EntityManager em : ems) {
      if(!(em instanceof EnvironmentAwareEntityManager)) {
        // Do your selection based on your needs
      }
    }
  }

  // ... delegate all calls to the result of select()
}
Comment by arjan tijms [ 24/Apr/13 ]

@c.beikov

With that method, how would you actually add a new persistence unit at runtime, or alternatively let an existing persistence unit point to a different database?

Comment by c.beikov [ 24/Apr/13 ]

Adding a new persistence unit is kind of tricky with the current state of the API. This is currently only possible my managing the EMFs within the application but you probably also have to depend on some code of the underlying persistence provider to do the dynamic configuration of the EMF. Transaction Management and so on could be handeled by using the new transaction interceptors of Java EE 7(at least I think that it would be possible, not sure about that). It is possible but not entirely with the standards provided by JPA.

The requirement was to switch PUs but not the underlying datasource of a PU. So when you know at deployment time what PUs you have you can do it like that.

I could still think of something else, but this is probably the worst solution. You could set a comment hint on every query you execute, let the address of the PUs database point to a proxy that does the selection by inspecting the comments.

Comment by jbsmathers [ 11/Nov/13 ]

This would allow the end user to make new db connections, and that would add a variety of functionalities not currently available in jee without redeployment. I have wondered about this since JEE5 and unless there are excellent reasons not to do it, I hope its in jee8.





[JPA_SPEC-13] Support use of EntityResult within ConstructorResult Created: 05/Dec/11  Updated: 04/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: ldemichiel Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: RFE

 Description   

Support use of EntityResult within ConstructorResult for result type mapping of native queries.






[JPA_SPEC-12] Addition of preCreate/postCreate callbacks for EntityManagerFactory Created: 05/Dec/11  Updated: 15/Apr/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: ldemichiel Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: RFE

 Description   

This would be useful hook for creation and/or modification of named queries.



 Comments   
Comment by ldemichiel [ 05/Dec/11 ]

We don't currently have a well-defined initialization sequence, and the EMF may be created by the container before application code gets to execute. However, a startup singleton EJB's postConstruct could be used for adding named queries, or a servlet init method.

Comment by c.beikov [ 15/Apr/14 ]

I have the feeling that JPA_SPEC-23 is also kind of related to this issue if a preCreate callback allowed for mutation of the meta- and physical model.





[JPA_SPEC-9] Dynamic specification of result type mappings for native queries Created: 05/Dec/11  Updated: 04/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: ldemichiel Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

API for specifying result type mappings. Currently this is handled through metadata, and is therefore static






[JPA_SPEC-3] Allow components other than stateful sessions beans to initiate container-managed extended persistence contexts Created: 05/Dec/11  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: ldemichiel Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It might be useful to support the use of container-managed extended persistence contexts in singleton session beans and/or application-scoped or conversation-scoped CDI components.



 Comments   
Comment by donatasc [ 05/Feb/13 ]

+100

IMHO this was a huge miss in Java EE 6. Even though CDI introduced conversation scope, injection/creation of extended persistence context EM was not mentioned at all. EJB spec is also silent about extended PC, what caused me to post message like this to JPA mailing list:
http://java.net/projects/jpa-spec/lists/users/archive/2013-01/message/51

In general, extended persistence context is largely under-specified in regards to integration between CDI/EJB/JPA.





[JPA_SPEC-109] Allow AttributeConverters to be CDI injectable Created: 11/May/15  Updated: 11/May/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Xavier Dury Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Since JPA 2.1, EntityListeners can be injected through CDI.

AttributeConverters could also be injectable in order to centralize conversion logic that can be shared between multiple components (like JSF Converters that will also be made injectable in 2.3).






[JPA_SPEC-108] Path.get(PluralAttribute<X, C, E>) lower bound missing on X Created: 28/Apr/15  Updated: 28/Apr/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: mmariotti Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Path interface declares:

<E, C extends java.util.Collection<E>> Expression<C> get(PluralAttribute<X, C, E> collection);

it should be instead

<E, C extends java.util.Collection<E>> Expression<C> get(PluralAttribute<? super X, C, E> collection);

with lower bound on X.
The same apply on Path.get(MapAttribute<X, K, V>).






[JPA_SPEC-100] Allow an empty collection_valued_input_parameter in an "IN" expression Created: 21/Feb/15  Updated: 21/Feb/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Anthony Ve Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In section 4.6.9, In Expressions, it should be specified that an empty collection_valued_input_parameter must not result in an exception. More specifically:

the expression
o.country IN (:countries)
must be treated as false

and the expression
o.country NOT IN (:countries)
must be treated as true

This should be trivial for JPA implementations to implement, since they can simply replace the expression with an expression like "1 = 0" or "1 = 1".

Currently, JPA implementations throw an exception in this case, which makes it cumbersome to use collection valued input parameters.






[JPA_SPEC-92] Sharing a single version field between multiple entities Created: 01/Oct/14  Updated: 01/Oct/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Xavier Dury Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have been using Hibernate then JPA for almost 10 years and there is one feature that I miss and would like to be discussed by the EG.

Currently, in JPA, with a typical (bi-directional & mapped) Parent-Child relationship, the parent gets versioned when a child is added or removed from the parent collection.

I would like to know if it is possible to version the parent when a child is updated without artificially updating a dummy property on the parent (let's say lastModificationDate).

I'd like to do that to preserve an objects' graph coherence (invariants).

example:

I have the following entities:

[Order] 1 --- * [OrderLine (quantity)] * --- 1 [Product (price)] 

and have a rule (at the order level that can be implemented with javax.validation) that the total amount for an order (= sum quantity * price for each line) must not be greater than $5000.

If two users concurrently modify the same order by changing the quantity of 2 different lines, the last one committing won't see the changes made by the first one (even if each OrderLine has a @Version property) and won't be able to enforce the invariants on the parent order.

However, if the order itself is versioned at each commit (even if none of its direct property has changed but one of its children has been modified), the last one committing will get an OptimisticLockException (and the order won't be corrupted).

Therefore, I would like to be able to specify something like this:

@Entity
class Order {

    @Id
    Long id;
	
    @Version
    Integer version;
	
    @OneToMany(cascade = ..., mappedBy = "order")
    Set<OrderLine> lines;
}

@Entity
class OrderLine {

    @Id
    Long id;
	
    @ManyToOne
    @Version // if this orderLine changes, bump the version of the whole order
    Order order;
}

That way, I could have a single version field for a graph of objects. Speaking with Domain-Driven Design in mind, this would result in having a version field only on the aggregate root.

What do you think?






[JPA_SPEC-84] Add support for EL expressions in JPA-QL and native queries. Created: 18/Jul/14  Updated: 19/Jul/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: thomasd Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This proposal suggests adding support using EL expressions in JPA query strings. With this one could define query string templates and dynamic parameter bindings based on EL (Expression Language).

  • Immediate evaluation (via $ {...}) could be used to statically alter the query string in cases where the user
    wants to statically generate a fixed part of a query. This could be used to add query fragments or adjust the name
    of tables or columns / fields.
    - Deferred evaluation (via #{...}

    ) could be used to dynamically compute a parameter value in cases where the user
    wants to avoid having to compute and set the parameter values explicitly.

Example 1

The JPA-QL query:

select o from BusinessObject o where o.owner.emailAddress like ?#{hasRole('ROLE_ADMIN') ? '%' : principal.emailAddress}

would translate to:

select o from BusinessObject o where o.owner.emailAddress like ?1

With ?1 bound to the result of the dynamically evaluated EL expression hasRole('ROLE_ADMIN') ? '%' : principal.emailAddress. The parameter ?1 would be dynamically registered.

Example 2

The JPA-QL query:

select o from BusinessObject o where o.owner.emailAddress = ?1 ${ currentTenant != null ? ' and o.tenant = ?#{' + currentTenant.id + '}' : ''}

would translate to either:

select o from BusinessObject o where o.owner.emailAddress = ?1

or:

select o from BusinessObject o where o.owner.emailAddress = ?1 and o.tenant = ?2

where ?2 is bound to the result of the dynamically evaluated expression "currentTenant.id".

It would be helpful to have some kind of SPI at the EntityManagerFactory that allows libraries or users to customize the EL expression context somehow, e.g. by allowing to expose functions, properties, variables and the like.

javax.el.Expression as JPA Query parameter values

As an extension one could also allow to bind parameter values of type javax.el.Expression to every exposed parameter of a JPA query. The value to be bound could then derived at query time by evaluating the given expression. We implemented that feature in the latest version of the Spring Data JPA Repository abstraction.



 Comments   
Comment by thomasd [ 18/Jul/14 ]

Sorry for the bad formatting...
I wanted to fix it, but I cannot edit the issue anymore

It should look like the following gist:
https://gist.github.com/thomasdarimont/96ca7a913c8b0ffcf970

Cheers,
Thomas





[JPA_SPEC-82] Add an EntityManager#getReference() method that takes an ID and a version Created: 01/Jul/14  Updated: 01/Jul/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: ljnelson Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Please consider adding an EntityManager#getReference(Class, Object, Object) method to the JPA specification.

The method's purpose should be to return an entity provided that its identifier and version are equal to the supplied parameters.

It should be possible to pass null as the third parameter (version).

The javadoc could read something like the following:

/* 
 * Get an instance, whose state may be lazily fetched, provided that the
 * supplied class, identifier and version parameters collectively identify the
 * persistent representation of the entity in question.
 *
 * <p>If the requested instance does not exist in the database, an 
 * {@link EntityNotFoundException} is thrown when the instance state
 * is first accessed. (The persistence provider runtime is permitted to throw
 * the {@link EntityNotFoundException} when {@code getReference} is
 * called.)</p>
 * 
 * <p>The application should not expect that the instance state will be  
 * available upon detachment, unless it was accessed by the application while 
 * the {@link EntityManager} was open.</p>
 *
 * @param entityClass the {@link Class} of the entity being sought; must not
 * be {@code null}
 * 
 * @param primaryKey the identifier of the entity being sought; must not be
 * {@code null}
 *
 * @param version the version of the entity being sought; may be {@code
 * null} in which case this method will behave in exactly the same manner as
 * the {@link #getReference(Class, Object)} method
 *
 * @return the found (non-{@code null}) entity reference
 *
 * @exception IllegalArgumentException if {@code entityClass} does not 
 * denote an entity type or {@code primaryKey} is not a valid type for that
 * entity's primary key or is {@code null}
 *
 * @exception EntityNotFoundException if the entity state cannot be accessed
 */

The background for this issue can be accessed in the following email thread: https://java.net/projects/jpa-spec/lists/users/archive/2014-06/message/0






[JPA_SPEC-81] @Version Support for Temporal Types Created: 22/May/14  Updated: 22/May/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: shelleyb Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The JPA 2.1 specification currently indicates that Timestamp is the only supported temporal type for @Version properties:

The following types are supported for version properties: int, Integer, short, Short, long, Long, Timestamp.

I'd propose that additional temporal types are supported as well:

java.util.Date, java.util.Calendar, java.sql.Date, java.sql.Time, java.sql.Timestamp



 Comments   
Comment by shelleyb [ 22/May/14 ]

For reference, Hibernate already seems to support this, and as such, we had initially overlooked this jpa limitation and are already using @Version java.util.Calendar in our entities, and I have observed this usage elsewhere as well:

https://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch05.html#mapping-declaration-timestamp





[JPA_SPEC-77] EntityManager(Factory) should implement AutoCloseable Created: 13/Apr/14  Updated: 28/May/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: braghest Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: autocloseable, java_7

 Description   

EntityManager and EntityManagerFactory have #close() methods but do not implement AutoCloseable. Implementing AutoCloseable would allow them to be used in Java 7 try-with-resource statement.



 Comments   
Comment by flutter [ 21/May/15 ]

This would mean to drop Java 6 support, right?

Comment by braghest [ 22/May/15 ]

That would mean dropping Java 7 support but then again Java EE 7 requires Java SE 7.

Comment by neilstockton [ 28/May/15 ]

It would mean dropping Java 1.6, yes. But then Java 1.6 and Java 1.7 are BOTH end of life now.
By the time the next version of JPA happens (who knows when that is), Java 1.8+ should be the baseline, hence no reason why this issue can't be included.
+1





[JPA_SPEC-68] update and/or validate javax.persistence.schema-generation.database.action Created: 12/Nov/13  Updated: 12/Nov/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: steveschols Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: schema-generation, update, validate

 Description   

I think that an "update" and a "validate" schema-generation.database.action might come in handy, especially for production environments where Java EE 7 will be running in the comming future.

Of course you don't want your database to be accidentally being removed if you still have the "create-drop" enabled, and a new action won't solve that.
But without the "update" action you still have to resort to solutions like Google Flyway or DbMaintain to update an existing database schema.

Are there plans to incorporate a new action like "update" or "validate", the way Hibernate supports it?
Or are they left out by design?






[JPA_SPEC-67] Incorrect code sample for @Convert Created: 09/Nov/13  Updated: 09/Nov/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: arungupta Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In the Java EE 7 downloaded javadocs, the first five samples for @Convert shows an incorrect usage of the annotation. They all use @Convert(BooleanToIntegerConverter.class) or something similar. This should be @Convert(converter=BooleanToIntegerConverter.class).

This is the case with the hosted javadocs at http://docs.oracle.com/javaee/7/api/javax/persistence/Convert.html as well.

The exact code snippet from javadocs is given below:

Example 1: Convert a basic attribute

@Converter
public class BooleanToIntegerConverter
implements AttributeConverter<Boolean, Integer>

{ ... }

@Entity
public class Employee { @Id long id; @Convert(BooleanToIntegerConverter.class) boolean fullTime; ... }


Example 2: Auto-apply conversion of a basic attribute

@Converter(autoApply=true)
public class EmployeeDateConverter
implements AttributeConverter<com.acme.EmployeeDate, java.sql.Date> { ... }

@Entity
public class Employee

{ @Id long id; ... // EmployeeDateConverter is applied automatically EmployeeDate startDate; }

Example 3: Disable conversion in the presence of an autoapply converter

@Convert(disableConversion=true)
EmployeeDate lastReview;

Example 4: Apply a converter to an element collection of basic type

@ElementCollection
// applies to each element in the collection
@Convert(NameConverter.class)
List<String> names;

Example 5: Apply a converter to an element collection that is a map or basic values.
The converter is applied to the map value.

@ElementCollection
@Convert(EmployeeNameConverter.class)
Map<String, String> responsibilities;



 Comments   
Comment by ldemichiel [ 09/Nov/13 ]

Yes, this is definitely an errata item.





[JPA_SPEC-65] Need another property to make lazy loading of attributes easy with entity graphs Created: 31/Aug/13  Updated: 31/Aug/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: mkeith Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There are currently two properties to use with entity graphs:

javax.persistence.fetchgraph -

This property accepts an entity graph to act as a complete override of all the attributes for the type. Attributes are dictated to be eager if included or lazy if excluded from the graph, regardless of how they are mapped.

javax.persistence.loadgraph -

This property offers a selective eager approach. One can simply add the attributes that one wants to be eagerly loaded and the rest are left as they are statically mapped.

The missing property would be something to allow more convenient selective lazy overriding without having to declare the entire attribute set for the type (as required by fetchgraph). So something like:

javax.persistence.lazygraph -

This property would offer a selective lazy approach. One would be able to add the attributes that one wants to be lazily loaded to the graph, with the rest being left as they are statically mapped.






[JPA_SPEC-64] EntityGraph API has unspecified List/Map getters Created: 27/Aug/13  Updated: 27/Aug/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: mkeith Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The List/Map getter methods (e.g. getAttributeNodes()) on EntityGraph, AttributeNode, and Subgraph do not specify whether the List/Map returned is a mutable one or a copy. They should be specified as returning the exact collections so the collections can be mutated. If it is a copy then the ability to mutate an existing named entity graph using createEntityGraph(String) is quite limited. There would be no way to remove an attribute node or a subgraph, or for that matter even add a subgraph for an existing attribute node.

The alternative to returning the actual collections is to add methods to the API to enable the additional mutating operations.






[JPA_SPEC-59] Clarify namespaces of type aliases and named parameters Created: 11/Jun/13  Updated: 11/Jun/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Matthew Adams Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

JPA 2.1


Tags: jpa, jpql, parameter

 Description   

JPA 2.1 Section 3.10.12, "Named Parameters", does not explicitly require that the namespaces of type aliases and named parameters be distinct. Some implementations fail & some succeed on JPQL of the following form:
SELECT x FROM Thing x WHERE x.foobar = :x

The specification should be explicit as to whether type aliases and named parameters share the same namespace.






[JPA_SPEC-53] Schema generation with existing EMF Created: 26/Mar/13  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Christian Bauer Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I've been running into a conceptual issue with schema generation in JPA 2.1 and how unit tests are typically organized.

Let's say you want a clean database for every unit test method. I prefer to create the schema in the database before every test method, and then drop it after the test method completes.

I have a single EntityManagerFactory for the whole test class, it can be shared by every test method. This is possible with the Hibernate API, the schema generator uses an existing EMF configuration to produce the create/drop scripts.

With the static Persistence.generateSchema() in 2.1 this approach doesn't work. Calling generateSchema() internally builds a new EMF every time.

One of the problems is that you get new automatically generated foreign key names every time you call generateSchema(). The "drop" action therefore always fails, unless you define all foreign key names in your metadata. There could be other automatically generated artifact names, so the "drop" action in general, if called from a static context, is not useful during development.

The current solution then is to specify "drop-and-create" and to build and close an EMF for every unit test method. This means starting and stopping the persistence provider for every test method, slowing down test runs significantly.

A better solution would be an additional Persistence.generateSchema(EMF, properties) method that accepts an existing EMF and some "override" properties.



 Comments   
Comment by Christian Bauer [ 04/Apr/13 ]

Additionally, consider adding the database action "create-drop". This would issue CREATE statements when the EMF is build, and DROP statements when the EMF is closed. Granted, this is a useless setting with static Persistence.generateSchema() but it would, in addition to the above proposed changes, give you full flexibility for schema generation. Use case is for example a @BeforeMethod in a test harness that builds an EMF and an @AfterMethod that closes the EMF.





[JPA_SPEC-52] createNativeQuery(String, Class) Created: 20/Mar/13  Updated: 05/May/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: agoerler Assignee: ldemichiel
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Hi,

I've got a minor suggestion:

EntityManager.createNativeQuery(String, Class)

could return a TypedQuery as the result class is specified:

TypedQuery<T> createNativeQuery(java.lang.String sqlString,
java.lang.Class<T> resultClass)

-Adrian



 Comments   
Comment by edvin [ 05/May/14 ]

Is there a more complex underlying reason for this not being fixed? At first glance it seems trivial.





[JPA_SPEC-42] Allow null @Embedded Objects Created: 17/Jan/13  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: reza_rahman Assignee: ldemichiel
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

At the moment, it is not possible to have null @Embedded objects in JPA (while Hibernate, etc allow it). This is quite a common scenario in most domain models that JPA should take into account. The following is an example:

<pre>
public class Employee {
...
@Embedded(optional=true) // This should be possible since the employee entity can be null in some
// stages of it's life-cycle
private Address address;
...
}
</pre>






[JPA_SPEC-30] Case sensitivity in JPQL queries Created: 24/May/12  Updated: 24/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: arjan tijms Assignee: ldemichiel
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: RFE

 Description   

In JPA 2.0, JPQL is case insensitive. This means that contrary to Java code, an identifier can not be same name as an entity with the first letter in lower case.

For instance in the following query an underscore has to be added to make the name legal:

SELECT
    _user
FROM
    User _user

Other typical workarounds for this are abbreviating the identifier to e.g. "u", "usr" etc. Such names are rarely a best practice and actually against common advice for good naming given by books like Clean Code, etc.

I would like to request support for case sensitivity in some way, or alternatively to lift the requirement that identifiers may not have the same name as Entity classes. This last approach is taken by some persistence providers, e.g. Hibernate, which silently accepts identifiers having the same name as Entities.

One possible solution would be to use a setting, either per query or globally for the entire persistence unit. E.g.

<named-query name="User.getAll" caseSensitive="true">
    <query>
        SELECT
            user
        FROM
            User user
    </query>
</named-query>


 Comments   
Comment by c.beikov [ 24/Apr/13 ]

Would it break backwards compatibility? I don't think so.
IMO this is an important addition when there is no reason for not including it. Many developers just use "propritary features" of their persistence providers and don't even know for sure that it isn't standard. I used hibernate ever since and I didn't know JPQL is case insensitive. So if I really want to deploy my applications to servers that do not have hibernate on them and the JPA implementation of the target system is not case sensitive, I would have to rewrite 300+ queries to get it working

Please consider the addition or give reasons for not doing it!





[JPA_SPEC-23] add a prefixing mechanism for @Embedded Created: 10/May/12  Updated: 15/Apr/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Mark Struberg Assignee: ldemichiel
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: RFE

 Description   

Currently working with @Embedded is not really user friendly. If you have multiple Embedded fields in an Entity, then you need to excessively use @AttributeOverrides to use them. This is not only a real nightmare to write down, but also an absolute pain when it comes to refactoring or if you just add or remove a column.

It gets even worse if you have a nested @Embedded structure!

The solution could be to allow specifying a 'prefix' as JDO knows it for years.

Let's first look at the Embeddable

@Embeddable 
public class Address {
  private String name1;
  private String name2;
  private String street1;
  private String street2;
  private String zip;
  private String tel;
  // ... + getters and setters
}

(please let's not argue about whether this should better be stored 1:n but just take it as sample for now)

Then we look at a possible solution with the prefix:

@Entity
public class Customer {
 ...

  @Embedded(prefix="S_")
  private Address serviceAddress;

  @Embedded(prefix="B_")
  private Address billingAddress;

  @Embedded(prefix="P_")
  private Address physicalAddress;
}

You all know what pain it is to do the same in JPA right now ...



 Comments   
Comment by mkeith [ 15/May/12 ]

Yes, this is a possiblity, although I'm not fond of mixing a logical annotation with a physical column prefix, but the idea is fine, and it wouldn't necessarily need to be part of the embedded annotation.
Prefixes would presumably not be applied to explicit overrides, so it would be more like a default prefix.
I suppose the prefix would apply to the nested embeddables as well?

Comment by Mark Struberg [ 20/May/12 ]

I see what you mean with the separation of the java side and the db side. Maybe you could see this as 'logical' prefix which by default gets mapped 1:1 to a column prefixing logic like with the column names?

As for nested embedded fields imo the prefixes should also get nested.

In our application we use a

@Embeddable
public LocalizedText {
  private String en;
  private String de;
  private String fr;
}

Now imagine that the Address class above has two fields private @Embedded LocalizedText comment with a prefix='C_' and internalInfo with prefix='I_'.

That would end up with the columns
S_C_name1, S_C_name2,.. S_I_name1, S_I_name2,... B_C_name1, B_C_name2,...

Comment by Paul Benedict [ 11/Apr/14 ]

I agree that mixing the logical and physical is not ideal (see comment #1). Besides, if someone wants prefixes, someone else is likely to want suffixes too, or some other complex customization. I propose that the developer should specify a class that can preprocess the column name. The benefit to this approach would be the spec wouldn't dictate/shoehorn the customizations allowed.

For example, called once per attribute of an emeddable/entity:

public interface PhysicalCustomizer {
  String customizeColumn(ManagedType<?> mt, Attribute<?,?> attr, String originalColumnName)
}

Sample usage:

@Embeddable
@Customizer(MyPhysicalCustomizer.class)
Comment by c.beikov [ 15/Apr/14 ]

I think this is related to JPA_SPEC-12 if mutation of the meta- and physical model in case of preCreated callback is allowed.





[JPA_SPEC-20] add FetchType.LAZY/EAGER to @Lob fields and @Embeddable Created: 10/May/12  Updated: 05/Apr/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Mark Struberg Assignee: ldemichiel
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Afaik there is currently no way to specify a @Lob field as being lazy loaded.

BLOBS and LOBS often need a big amount of memory and are expensive to fetch from the database.

What about adding something like:

public class MyEntity {

  @Lob(FetchType.LAZY)
  private String someHistoryData;

}

Currently one always needs to create explicit list objects which get filled with 'new' in JPQL to not trash the database.

The same goes for @Embeddable. Though not needed that desperately it could be useful as well. (The whole Embedded would get lazily fetched when a single attribute of it is read).



 Comments   
Comment by Mark Struberg [ 14/May/12 ]

small note: it's for sure better to define the FetchType in each @Embedded and not in @Embeddable.

Comment by mkeith [ 15/May/12 ]

You can actually combine @Lob with @Basic, allowing you to specify a fetch type for any Lob attribute. I think this will give you what you want.

As far as Embedded objects go, any one of the embedded attributes can be individually specified to be lazy loaded but there is not currently a standard way to say that the embedded object should be lazy loaded as an object. My personal opinion is that if you get to that point then you are probably bordering on considering the embeddable as an independent privately owned entity and should make a relationship out of it instead of an embeddable, but that may just be me. We could get to the stage of adding a fetchType element on @Embedded, or we could handle this case through entity fetch groups.

Comment by ldemichiel [ 15/May/12 ]

I think it is reasonable to add FetchType to @Embedded. When we first introduced embeddables they were more limited in terms of what attributes they could have.

Comment by Mark Struberg [ 20/May/12 ]

Mike, Linda, thanks for pointing me to @Basic. I was actually not aware that I can use both @Basic and @Column on the same field - my fault. I always thought that @Column was a successor of @Basic, mostly because they have conflicting properties. E.g. having a

@Basic(optional=false)
@Column(nullable=true)
private String xxx;

lets me without a clue what should happen. But that is certainly another (minor) problem.

As for FetchType for Embedded fields: this is certainly not as big as an issue for the (now solved) @Lob question. Downgrade to minor? txs!

Comment by ldemichiel [ 30/Oct/12 ]

Downgraded priority to reflect comments





[JPA_SPEC-19] Upload official/standard JPA 2.0 API jar to Maven Central Created: 05/Apr/12  Updated: 13/Jun/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Matthew Adams Assignee: ldemichiel
Resolution: Unresolved Votes: 13
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: bundle, maven, mavenization, osgi, repositories, repository

 Description   

There is no official or standard JPA API jar available from the expert group in either Maven Central or the java.net Maven repo that both JPA users & implementors can utilize. Users are left to search for implementations' groupId, artifactId, & version values, which is inconvenient.

Please upload a binary jar (including class files and relevant resource files), a source jar, and a javadoc jar, under the groupId "javax.persistence", artifact id "jpa-api" and version "2.0". A minimal target Maven repository would be Maven Central, but others like java.net might be nice, too.

Bonus points for including OSGi bundle metadata (pretty easy if using Apache Felix's Maven Bundle Plugin, org.apache.felix:maven-bundle-plugin:2.3.7)!



 Comments   
Comment by Matthew Adams [ 13/Jun/13 ]

http://search.maven.org/#artifactdetails%7Cjavax%7Cjavaee-api%7C6.0%7Cjar

Is this intended to be the release? If so, it might do for some, but a standalone JPA API artifact would be ideal.





[JPA_SPEC-101] Typo in the specification Created: 21/Feb/15  Updated: 21/Feb/15

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Anthony Ve Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In section 4.12 of the specification (JSR 338 JPA 2.1 Final Release for Evaluation), "wrappered" should be "wrapped".






[JPA_SPEC-95] javadoc compilation prints out warnings on JDK8 Created: 12/Oct/14  Updated: 12/Oct/14

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Lukas Jungmann Assignee: ldemichiel
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Javadoc generation currently reports 441 warnings on JDK 8, it would be nice to get this to 0 warnings

 
 [javadoc] /Users/lukas/development/eclipselink/javax.persistence/src/javax/persistence/criteria/Subquery.java:178: warning: no @param for <V>
  [javadoc]     <X, K, V> MapJoin<X, K, V> correlate(MapJoin<X, K, V> parentMap);
  [javadoc]                                ^
  [javadoc] 441 warnings





Generated at Tue Jul 07 03:03:31 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.