Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rewrite section on Portability for Relational Databases #469

Merged
merged 2 commits into from
Feb 22, 2024
Merged

rewrite section on Portability for Relational Databases #469

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
96a5f3f
rewrite section on Portability for Relational Databases
gavinking Feb 21, 2024
fbe5a39
rework section on interop with JPA
gavinking Feb 22, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 4 additions & 5 deletions spec/src/main/asciidoc/jakarta-ee.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -82,15 +82,14 @@ When a repository method is annotated with an interceptor binding annotation, th

=== Jakarta Persistence

When integrating Jakarta Data with Jakarta Persistence, developers can leverage the JPA annotations to define the mapping of entities in repositories. Entities in Jakarta Persistence are typically annotated with `jakarta.persistence.Entity` to indicate their persistence capability.
When integrating Jakarta Data with Jakarta Persistence, a developer uses the annotations defined in `jakarta.persistence` to specify the object/relational mapping metadata for entity types stored in a relational database.

A Jakarta Data provider that supports Jakarta Persistence allows you to define repositories for classes marked with the `jakarta.persistence.Entity` annotation.
According to the Jakarta Persistence specification, every entity class should be annotated `jakarta.persistence.Entity`. Jakarta Data places an additional interpretation on this annotation, treating it as an entity-defining annotation.

By supporting Jakarta Persistence annotations, Jakarta Data providers enable Java developers to utilize familiar and standardized mapping techniques when defining entities in repositories, ensuring compatibility and interoperability with the respective technologies.
Thus, a Jakarta Data provider which supports Jakarta Persistence is able to supply an implementation of any repository whose associated entity classes are marked with the `jakarta.persistence.Entity` annotation. Typically, such an implementation simply delegates operations declared by the repository interface to the Jakarta Persistence `EntityManager`. Management of persistence contexts and integration with Jakarta Transactions remains the responsibility of the Jakarta Persistence provider.

==== Persistence Context
By supporting Jakarta Persistence, a Jakarta Data provider enables Java developers to utilize familiar and standardized mapping techniques when defining entities associated with Jakarta Data repositories, ensuring compatibility and interoperability with the respective technologies.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All this is easier to specify if I can talk about it in terms of @Insert vs @Persist if you get my drift.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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 EntityManager with 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 of jakarta.persistence.EntityManager. In particular, the repository observes the semantics of the Jakarta Persistence CascadeType.
  • 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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad, I did not see this discussion.


=== Jakarta NoSQL

Expand Down