[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-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: 0
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-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-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-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-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-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: 1
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.






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.






[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: 0
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-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-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: 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: 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





[JPA_SPEC-35] Support for more Java types Created: 06/Aug/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: 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());





[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-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-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-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-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-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-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-47] Usability of @Enumerated and @MapKeyEnumerated Created: 11/Feb/13  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: jd3714att Assignee: ldemichiel
Resolution: Unresolved Votes: 4
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.





[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-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-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: 1
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
    )




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-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-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: 6
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-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: 3
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-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-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-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: kalgon 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-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-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-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: 3
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-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-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-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: 12
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-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: 0
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-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





[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".






Generated at Fri Feb 27 01:32:15 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.