rewrite section on Portability for Relational Databases #469
Conversation
|
By the way, at this point, with so many of the foundations already in place, it would take me approximately an hour or two to add Just a thought. I know we said we weren't going to do it in this release, but we've come a long way since then. |
in particular, remove language about persistence contexts being non-stateful, since JPA itself does not currently allow this
|
I have pushed a second commit, which reworks section 6.4 on interop with JPA. This does change semantics, since the current version says that JPA-backed repositories must by stateless, but JPA doesn't support that. TANGENTIAL: the TCK has a test repository ( |
|
|
||
| Repository operations must behave as though backed by a stateless Entity Manager in that persistence context is not preserved across the end of repository methods. All entities that are returned by repository methods must be in a detached state such that modifications to these entities are not persisted to the database unless the application explicitly invokes a `Save` or `Update` life cycle method for the entity. |
There was a problem hiding this comment.
I realize the stateless EntityManager didn't make it into Jakarta Persistence 3.2, but it would be nice to be able to standardize the behavior in anticipation of it. I think it should be possible to simulate the behavior with what is currently in the Jakarta Persistence API unless I'm missing something. Although I suppose it will be somewhat inefficient to do so. I don't really like leaving it so unclear in the Jakarta Data spec, which leaves the user wondering what behavior they will end up with, or maybe assuming a behavior that is not the right one.
There was a problem hiding this comment.
OK so as I've argued elsewhere the implementations don't in principle need to wait for permission from the JPA spec to offer stateless sessions. So if you want me put back in something about this approach, that's totally fine, but I want it to be clear that you can also have a repository backed by a regular stateful session, and the previous language sounded like it was disallowing that.
There was a problem hiding this comment.
I think @otaviojava already merged this one on the basis of my review of the first commit. Apparently git doesn't reset the review status when more commits are added. We will need to ensure this discussion doesn't get lost because the change has been applied already.
There was a problem hiding this comment.
All this is easier to specify if I can talk about it in terms of @Insert vs @Persist if you get my drift.
There was a problem hiding this comment.
I think @otaviojava already merged this one on the basis of my review of the first commit. Apparently git doesn't reset the review status when more commits are added. We will need to ensure this discussion doesn't get lost because the change has been applied already.
Don't worry Nathan I can write this up tonight if we agree on the basic idea.
There was a problem hiding this comment.
@njr-11 So how about something like this:
A Jakarta Data provider which supports Jakarta Persistence entities bearing the annotation jakarta.persistence.Entity may support either or both of the following repository styles:
- A repository might be backed by a Jakarta Persistence
EntityManagerwith a stateful persistence context. The lifecycle operations of the repository are annotated with the Jakarta Persistence-specific annotations@Persist,@Merge, and friends, and follow the semantics of the corresponding standard operations ofjakarta.persistence.EntityManager. In particular, the repository observes the semantics of the Jakarta PersistenceCascadeType. - Alternatively, a repository might by "stateless", in the sense that it does not maintain a persistence context which outlives the invocation of a single repository method. The lifecycle operations of this kind of repository are annotated
@Insert,@Delete, or@Update, and adhere to the usual semantics of these annotations. In particular, these operations never cascade to related entities.
That's just a first cut, of course.
There was a problem hiding this comment.
My bad, I did not see this discussion.
I was not happy with section 7.1, so here's what I think it should say.
At least, something like this.
Thoughts?