JPA.next - Thinking about the Future

It's already close to 4 months since we released JPA 2.0, so it's time to start planning for the next release.

JPA 2.0 was strongly influenced by input that we received from the Java developer community, and many of the new features and improvements in JPA 2.0 were added and prioritized in response to developer feedback.

These include all of the following (and more!):

  • collections of basic types
  • collections of embeddables
  • nested embeddables
  • persistently ordered lists
  • orphan removal
  • pessimistic locking
  • foreign key mappings for unidirectional one-to-many relationships
  • improved support for maps
  • criteria query API
  • improvements to JPQL, including collection-valued in-expressions, more generalized support for operators and functions, and restrictions on query polymorphism
  • further standardization of configuration properties and hints

Feedback from the community is very important to us, so please share your thoughts on where you think we should go next. What features do you think are most important to add in JPA 2.1?

Feel free to comment here, and please also share your input by posting to the JPA 2.0 feedback list, jsr-317-feedback@sun.com. Input sent to it forwards to all of the members of the JPA 2.0 expert group for consideration.

Thanks!

Comments:

I know I won't be the last but manual flush mode please. I know we all clamored for it with JPA2, but not sure what the argument against it was.

Posted by Jason Porter on March 29, 2010 at 08:49 AM PDT #

it would be nice to have the equivalent of hibernate's FlushMode.MANUAL

Posted by Xavier Dury on March 29, 2010 at 07:52 PM PDT #

Hi Linda,

First of all thanks a lot for the great work on JPA 2.0!

Here is one of my wishes for JPA 2.1:

What I'm really missing on JPA is access to the change set the provider creates before an update. Today it's not possible to get a list of changes made on the entities.
That's one of the only point where I always need direct access to Hibernates PostUpdateEventListener and where I can't use JPA EntityListeners mechanism.

It would be great to have a standardized way of accessing the change set and more information on the currently running transaction.

Kind Regards,
Simon

Posted by Simon Martinelli on March 29, 2010 at 10:15 PM PDT #

Isn't FlushMode.COMMIT the equivalent of FlushModel.MANUAL? It defers the flush until commit, or until you call Flush. Seems like the same thing.

Suggestions:

Standard set of test cases to ship with spec. (Why wait for 2.1? Do it now!)

Posted by Pierce Wetter on April 13, 2010 at 02:52 AM PDT #

@Pierce

Commit is not the same unfortunately. I may have an entity manager that stays open longer than a transaction, and I may not want to persist to the database at commit as well.

Imagine I have a wizard like form that takes you through a series of steps. You can cancel the wizard at any time. If you cancel and don't complete the process either the records that were persisted need to be removed, or with a manual flush option I can flush once at the end of the wizard (keeping state in a conversation or a session) and just write to the database once. That's the power of having a manual flush. I'm not done with my unit of work, so don't write anything until I tell you to, when I'm done with the unit of work.

It would be the same in a desktop / fat client application, why commit things to the database and have to possibly clean it out if I don't need to?

Posted by Jason Porter on April 13, 2010 at 03:09 AM PDT #

Both Hibernate (Envers) and EclipseLink support an audit trail/versioning API.

Seems like a natural thing to standardize.

Posted by Pierce Wetter on April 14, 2010 at 04:15 AM PDT #

+1 on audit trail / versioning API

Posted by Jason Porter on April 14, 2010 at 04:23 AM PDT #

Read only entities would be good enhancement.

If the data comes from a view or from an other system in most cases this data is not updatable.

Posted by Simon Martinelli on April 14, 2010 at 07:34 PM PDT #

+1 for changed set. You will finally be able to execute some triggers logic.

The possibility to use EntityManager in entity life-cycle (EntityListeners) events like @PrePersist is also something I miss.

Posted by Radu B on April 16, 2010 at 01:44 AM PDT #

My wishes (more likely for JPA 3.0 ;-):

\* fetch- and merge-plans
\* declaring relationships as optional/mandatory so that the query-engine can choose on its own whether to use inner-joins or left-outer-joins
\* Down-casts in joins: select employee e join (MaintenanceProject)e.projects p where p.propertyOnylInMaintenanceProject = 'value'
\* metamodell with more information at runtime: length/type of corresponding column, all declared (proprietary) annotations, etc.

Posted by Frank Schwarz on April 16, 2010 at 04:36 PM PDT #

One more wish for JPA 2.1:

It would be great if there were more sensible column-naming rules for embeddables: This one for example is impossible without @AttributeOverrides:

public class Car {
@Embedded private Weight basicWeight;
@Embedded private Weight maxWeight;
}

public class Weight {
private BigDecimal value;
@Enumerated WeightUnit unit;
}

Why not generating column-names like basicweight_value, basicweight_unit, etc. by default?

Posted by Frank Schwarz on April 16, 2010 at 04:50 PM PDT #

- Enhanced sorting/ordering support (e.g. using comparators), see Hibernate's @Sort
- Native query elements within Criteria API

Posted by Adrian Hummel on April 18, 2010 at 09:31 PM PDT #

- persitence-test.xml configuration file for unit testing with maven

Posted by Stan Svec on April 19, 2010 at 10:19 PM PDT #

It would be great to include support for queries by example. I understand OpenJPA offers this as extension to CriteriaBuilder API.

Posted by Jaro Kuruc on April 29, 2010 at 07:14 AM PDT #

I would like nonproprietary enum support for legacy databases where column values are ordinals that are not sequential. This is common in some industries, such as pharmaceuticals where data providers use discontinuous integers to represent various states. Right now, this requires me to use <object-type-converter> in EclipseLink. To quote an EclipseLink bug, we need something like this:

// EXAMPLE USE:

@Entity
public class Order {
...
public enum Status {
@EnumValue(value="N")
NEW,
@EnumValue(value="S")
SHIPPED,
@EnumValue(value="C")
CLOSED
}
}

but in this case, we also need ordinal support as well.

Posted by Edward Rayl on May 06, 2010 at 03:30 AM PDT #

+1 on audit trail / versioning API

Posted by Reto on May 14, 2010 at 02:50 AM PDT #

Is there any implementation available, which is fully JPA 2.0 compatible? 'til now I haven't found any :(

Posted by Jens Elkner on June 19, 2010 at 03:13 AM PDT #

+1 on audit trail / versioning API

Posted by Duncan Carter on July 15, 2010 at 01:57 AM PDT #

+1 on audit trail / versioning API

Posted by Hansi Müller on July 21, 2010 at 03:30 PM PDT #

+1 on:
- audit trail / versioning API,
- FlushModel.MANUAL,
- enum support for legacy databases,
- more sensible column-naming rules for embeddables,
- queries by example and changed set

all these are situations where I use hibernate on a day-to-day

Posted by Gilliard Cordeiro on July 27, 2010 at 01:24 AM PDT #

+1 on:
audit trail / versioning API;
FlushMode.MANUAL;
more sensible column-naming for embeddables;
access to the change set the provider creates before an update.

Posted by Geraldo Luiz on August 25, 2010 at 10:30 PM PDT #

I would like to have custom converterts to do the conversion of the content of the database field to any Java type.

Posted by Simon Martinelli on August 25, 2010 at 11:06 PM PDT #

Hi Linda,

One of my biggest requests is remote Criteria. This is for use within Java client applications. This was missed out in JAP 2.0. As a reference look at Hibernate's DetachedCriteria.

We could use the MetaModel on the client to create remote criteria instances as no EntityManager would be available.

What are the chances of this?

regards,
--
Darren

Posted by Darren Bell on September 09, 2010 at 03:12 AM PDT #

+1 on
- DetachedCriteria support in JPA 2.1

Posted by Zuber Saiyed on September 15, 2010 at 06:47 AM PDT #

We need outer joins with conditions in an ON clause.

Let's say you want a list of car dealers and how many new vehicles they're selling.

In SQL you can say:

SELECT d.name, count( v.id ) FROM dealer d LEFT OUTER JOIN vehicle v ON v.dealer_id = d.dealer_id AND v.type = 'New' GROUP BY d.name

In JPQL, you only have the WHERE clause which limits your results, making the outer join useless:

SELECT d.name, count( v.id ) FROM dealer d LEFT OUTER JOIN d.vehicleList v WHERE v.type = 'New' GROUP BY d.name

This is so basic. Let's not forget why we have JPA. Back to reality please.

Posted by Bernard on September 15, 2010 at 08:43 AM PDT #

+1 on outer joins with conditions in an ON (WITH) clause.
Hibernate has this but it has (or had - I haven't checked the latest version) an implicit limitation that the WITH condition can specify criteria which mentions alias of the target joined entity only. It would be great if this limitation is lifted in a JPA 2.1 spec (so that Hibernate would finally have to be fixed :-)

Posted by Peter Levart on October 11, 2010 at 05:22 PM PDT #

From the spec: "An embeddable class (including an embeddable class within another embeddable class) that is contained within an element collection must not contain an element collection, nor may it contain a relationship to an entity other than a many-to-one or one-to-one relationship."

What's the reason for this? Could this limitation be overcomed?

I'll find also useful some way to ask for loading some/all lazy fields when you know that the entity is going to be detached. I find kind of ugly calling something on the fields just to load them.

+1 on:
- query by example
- standard set of test cases to ship with spec

Posted by Xavier Sanchez on October 13, 2010 at 04:06 AM PDT #

I would like to have integration with dependency injection jsrs(330,299).

An standard response to things like Spring @Configurable annotation.

Posted by Ali Ebrahimi on December 01, 2010 at 06:40 PM PST #

+1 on:
- outer joins with conditions in an ON (WITH) clause
- enum support for legacy databases

Please let javax.persistence.criteria.Fetch be a javax.persistence.criteria.Join otherwise we are not able to express the following query with the criteria-api:
select distinct xx from Currency xx
left join fetch xx.companies comp
where comp=:comp

Posted by Valentino on December 06, 2010 at 12:38 AM PST #

What about API to check whether a collection is initialized or not in the case of lazy loading?

I would also like to give support for transforming a JPQL query into a criteria query. One important use case I see is starting with a base query in JPQL, and then using a criteria to add small variants to it. Like a single extra condition in the where clause.

Currently I need to duplicate a lot of named queries when I only need to add a single small condition. Defining them from the start as a criteria query would be an option, but this not as nice for readability as JPQL is.

Posted by henk on December 20, 2010 at 06:32 AM PST #

Public TCK.
Fetch groups.
Fluent typesafe API like QueryDSL.

In fact many things that JDO already offers.

Posted by Neil on December 22, 2010 at 04:59 PM PST #

- transactional like spring. Annotating a method would mean that transactions could be taken care of.
- auditing like envers
- possibly make the jpaql driver separate like dbase jdbc drivers. As such the jpa framework is not tied to the jpaql driver meaning you can pick and mix. It would allow dbase companies to create the driver with more orientation towards performance. What i have found is if their is a bug in hibernates conversion to sql you are donald ducked. It would allow the 2 jpa ql and criteria to be improved separately from the main jpa framework which should come with reference implementation in standard java.
- push back to change java as a core language to help the development of jpa.
. the compiler should automatically create the acccessors ie getter and setter without having to directly code them. They can obviously be overwitten for customising. This could be done in a variety of ways. Add a new local variable type and all private instance variables automatically create the setters and getters when code is compiled, annotate with in and out = protected if you do not want default public accessors. May have a class level annotation to turn this on. Off course as a prelude to this jpa annotations should be on the instance variable and not the getter.
. the problem with named queries and the jpaql is that they are simply strings. Change then name of it and the code breaks. The jpaql should should be using the ide to help, and code should be tested at compile time. Instead of just using annotations being part of the jpa should allow pusing back to the core language to sort out this issue instead of the work arounds used by hibernate with annotations. As such possibly add a new jpaql type. The jpaql would not be not in quotes and end with semi colon. Off course updating the annotations so the name is not in quotes either and code uses the actual name and not the string value would stop errors at runtime due to typos or string name changes.
-have a doa=true annotation that would generate a DOA for the user at compile time. This could be within the same enntity class file. This would remove the calls to the entity manager for the developer which is simply injected to the class entity or separate dao. As such it would be things like entityname.persist or entityname.findAll, entityname.findbyid, entityname.jpaqlnamedquery. The compiler automatically generating this cofigurable by the jpadoa annotation. Using getEntityMgr from the entity would give the developer access to that for other things like flushing etc where specific entitymgr calls are requied.
-option to put named queries in a separate file from entity with default name entityql. This should include the criteria too. Named criteria should sit alongside names queries in the same class.
-Increase the ability for the standardised jpa to be used by tools. Entities should be opened graphically in ide. As such removing customised code from the entity is important. In this day and age we should simply see a gui screen of the entity and not code. Keeping the entity clean would allow better synchronizing with the dbase. Developing the jpa layer should be easy. You create your logical design uml. Your ERD and the entities and associated queries. There should be littel reason for code or to view code. Where it is necessary the developer could simply extend the entity class or ways to inject code can be looked at. The entities should really simply be oject mappings of the relational database. If code is needed for the defficiency of the jpa itself then that itself should be fixed. ie like missing auditing like envers.

I would propose that to enable this having a new jxml file that compiles to a java class should be brought in. This would prevent hacking the entity with code losing the ability of the gui to represent the class. We have moved from xml configuring the class to annotations on the class whihc is better than having 2 file to maintain. Having a simple xml xsd file that compile to a class would enable ide to really gui-ify the whole jpa work. Again that pushes back to the core language.
- ability of the jpa to deal with stored procedures and functions at they are always needed/used in projects whether we like it or not.

Posted by Alan B on January 12, 2011 at 07:35 PM PST #

+1 on:
Native SQL queries within Criteria queries
Fetch groups
Full metamodel information (all annotation information)

Posted by Gerald Glocker on March 02, 2011 at 08:08 AM PST #

Remove the constraint that Entities must have a field that represents the primary key of the database table. This can be completely transparent to the developer. It could be generated by the persistence provider or the persistence provider could manage it in another way.
In addition the persistence provider should handle the correct working of equals and hashCode. It is clearly defined by database semantic which entities should be equal. Why does the developer has to implement equals and hashCode again and again for every new entity.
Every existing persistence provider uses encapsulation of entities either by proxying or by byte-code-enhancement. It should be no problem to add id-field-handling and proper handling of equals and hashCode...

Posted by Arne Limburg on March 16, 2011 at 11:48 PM PDT #

Native Queries mapping for non-entity class
It would be nice to have posibility to pass the simple pojo class for native queries.Currently we can pass the objects which are Enities or we need to manually go through list of objects[] and assigned values to simple pojo's. This is really bleee... :). It could be example

class Test{
Integer id;
String name;
}

em.createNativeQuery("select new id,name from test_table",Test.class) <-but not entity required

What do you think. This is in case when we have a special native queries and no entities for it ?

Posted by Tomasz Bożek on March 18, 2011 at 06:21 PM PDT #

Update.

I've just read the spec for 2.1

Improved support for the result type mapping of native queries

Maybe this is my request ?

Posted by Tomasz Bożek on March 18, 2011 at 06:26 PM PDT #

Not sure if this would fall under JPA or EJB but I'd like to see a way of specifying a default PU in the persistence.xml. eg:

<persistence ...>
<persistence-unit name="foo" ... />
<persistence-unit name="bar" ... />
<default-unit>bar</default-unit>
</persistence>

Then anytime a @PersistenceContext is injected without specifying a unitname the value of default-unit would be used. That would nicely solve this and make switching into a test context much simpler then it currently is.

Posted by NW on March 21, 2011 at 07:34 AM PDT #

Add view object classes rather than just entity objects. As such you would have either a jpa ql or native ql in a class and have it mapped to the properties. The view object would be query driven. Effectively the weakness of jpa is when a project is query driven rather than crud. Bringing in some of the functionality of ibatis would therefore be good.

Rather than having annotated named queries a new jpql type should be created. The query should not be a string eg

Jpql findAddesses = select a from Address a;

This would mean the jpql would use the object to compile at compile time of the object.

Annotations are useful for hibernate but with the JPA core things like a Jpql type can be created in the language itself.

Posted by Alan B on March 29, 2011 at 09:18 PM PDT #

Please make sure, that method-validation (Bean-Validation 1.1) will be available for Entity-Beans out of the box.

Posted by Arne Limburg on April 09, 2011 at 05:13 PM PDT #

The biggest issue I have is real usable events; this means that in before update or insert event, or maybe even in the post events, it is possible to make changes to other entities.
I've got a BM that I use in a fat client, in batch processes, in a SOAP interface, and some code has to be repeated in each layer because the events cannot do this. I would like the concept of an encapsulated business model. Maybe the current spec is leaning too much toward EJB usage with its session beans.

Posted by Tbee on April 14, 2011 at 03:49 AM PDT #

What I really miss using JPA is Criteria Queries like Hibernate provides. In particular, it would be fantastic if we just could use the whole Hibernate Criteria Queries through JPA Entity-manager. This would allow me to use JPA and my favorite DAO:

public interface IDAO {

public Object findById(Class<?> clazz, Object id,
FetchConfig[] fetchConfigs, LockMode lockMode);

public Object findById(Class<?> clazz, Object id);

public Object findByValue(Class<?> clazz, Restrictions[] restrictions,
FetchConfig[] fetchConfigs, LockMode lockMode);

public Object findByExample(Object exampleObject, String[] excludes,
LockMode lockMode);

public List<?> listByExample(Object example, FetchConfig[] fetchConfigs,
Restrictions[] restrictions, Order[] orders, int firstResult,
int maxResult);

public List<?> list(Class<?> clazz, FetchConfig[] fetchConfigs,
Restrictions[] restrictions, Order[] orders, int firstResult,
int maxResult);
}

public class FetchConfig {

private String table;
private FetchMode fetchmode;

public FetchConfig(String table, FetchMode fetchMode){
this.table = table;
this.fetchmode = fetchMode;
}

public String getTable() {
return table;
}
public void setTable(String table) {
this.table = table;
}
public FetchMode getFetchmode() {
return fetchmode;
}
public void setFetchmode(FetchMode fetchmode) {
this.fetchmode = fetchmode;
}
}

Posted by Albert Timel on April 15, 2011 at 01:11 PM PDT #

add EntityManagerFactory.getCurrentEntityManager() which retrieves the current transaction-scoped EntityManager (à la Hibernate SessionFactory.getCurrentSession()).

Posted by Xavier Dury on April 20, 2011 at 05:19 AM PDT #

Annotation for defining db index on fields (columns);

Posted by Ali Ebrahimi on April 23, 2011 at 04:58 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Linda DeMichiel is the Specification Lead for Java EE 7 and for Java Persistence 2.1, and a member of the Java Platform, Enterprise Edition team at Oracle. She was formerly the Specification Lead for JPA 2.0 and for EJB 3.0.

Search

Top Tags
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today