| Re: [jpa-dev] Jakarta Persistence.Next? |
I too would be keen on understanding how this important and very widely used specification can move forward.
From my perspective, the current Ambassadors' Jakarta EE 10 contribution guide draft has the right big ticket items for Jakarta Persistence: https://docs.google.com/document/d/1uZFBoIujXCc-gQhCzh_ZdlKEsrsV0yVVIHzBTI3usF8/edit?usp=sharing. That said, more feedback I think would be a good thing.
For better or worse, this is one of those technologies that are
far too intricate to be solely driven forward by end users. While
end users could definitely help, I think major changes have to be
driven by more established vendors. So it would be great to get
some thoughts from these folks soon.
Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual
community member and do not reflect the views of my employer.
Hi,
With Jakarta 9 and Jakarta Persistence 3 in the bag, it may be time to start planning for the Persistence in Jakarta EE 10.
Is there anyone who has already some plans for this, or ideas when to start?
For starters, there's a large number of issues in the backlog that are still really useful. For instance, I'd still love to see this one happen:
I filed that in 2014, and it asks for more fine grained control over data that should *not* be loaded.
This one from 2015 is, at least IMHO, still a big problem as well:
I still very often have to write a query twice, then programmatically check if the parameter list is empty, and then choose one of the two based on the outcome.
Improved pagination support would also be much appreciated, as this is such a common thing:
For more flexibility, being able to transform from JPQL to Query and Criteria and the other way around would also be really good to have:
Thoughts?
_______________________________________________ jpa-dev mailing list jpa-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jpa-dev