remove integration with Jakarta Persistence#480
Conversation
This is currently not well-defined, and so if we're unable to reach consensus, we can slip this feature to the next release of Jakarta Data.
njr-11
left a comment
njr-11
left a comment
There was a problem hiding this comment.
This looks good. I added one comment to consider because I think the intent in that case was only to prevent the widespread reuse of jakarta.persistence.Entity by Jakarta Data providers for non-relational, causing it to longer be useful as a way of disambiguating the provider.
| - The `jakarta.persistence.Entity` annotation from the Jakarta Persistence specification is an entity-defining annotation for Jakarta Data providers backed by a Jakarta Persistence provider. Other Jakarta Data providers must not support the use of `jakarta.persistence.Entity` as an entity-defining annotation. | ||
|
|
||
| - The `jakarta.nosql.Entity` annotation from the Jakarta NoSQL specification is an entity-defining annotation for Jakarta Data providers backed by NoSQL databases. Other Jakarta Data providers must not support the use of `jakarta.nosql.Entity` as an entity-defining annotation. | ||
| In particular, the `jakarta.nosql.Entity` annotation from the Jakarta NoSQL specification is an entity-defining annotation for Jakarta Data providers backed by NoSQL databases. Other Jakarta Data providers must not support the use of `jakarta.nosql.Entity` as an entity-defining annotation. |
There was a problem hiding this comment.
Are you sure we should remove this one? This is guarding against someone coming along and writing a provider for some random data store and deciding that it would be easier to use jakarta.persistence.Entity for their entity-defining annotation because they don't feel like publishing a com.myrandombusiness.MyEntity annotation of their own. Then their provider will collide with all Jakarta Data providers that more appropriately use jakarta.persistence.Entity for relational data access which will force users to disambiguate everywhere via provider = ....
Git isn't allowing to me to add a suggestion here, but maybe we could use the terminology,
"... for Jakarta Data providers backed by a relational database."
if we don't want to specifically mention Jakarta Persistence here.
There was a problem hiding this comment.
I'm completely happy to leave that bit in.
3 participants
If we're unable to reach consensus on #477, then we should just go ahead and slip support for Jakarta Persistence until a future version of Jakarta Data, hopefully after Jakarta Persistence itself starts to support a stateless programming model (a feature I proposed a while ago, but which did not make it into JPA 3.2).
This PR demonstrates that we can leave JPA support undefined in this release without doing any real violence to the spec as it exists today.