[Use Case]: Annotations for use with Jakarta Persistence
- Dominant language
- Java
- Stars
- 150
- Forks
- 37
- Avg merge
- 4d 4h
- Merged PRs (30d)
- 34
Description
### As a ...
- [ ] Application user/user of the configuration itself
- [X] API user (application developer)
- [ ] SPI user (container or runtime developer)
- [ ] Specification implementer
### I need to be able to ...
write a portable repository backed by JPA.
### Which enables me to ...
be more independent of the Jakarta Data provider.
### Additional information
So I know we all said we didn't want to do this in this release. But with all the machinery we've defined, it's now frankly trivial.
We would add:
- lifecycle annotations `@Persist`, `@Merge`, `@Refresh`, `@Lock`, `@Remove`, and `@Detach`, and
- query annotations `@JPQL` and I guess also `@SQL`
in new package `jakarta.data.orm`.
The semantics of the lifecycle annotations are completely defined by the JPA spec. Because they're specific to JPA/ORM, we have zero work to do, it's just a `@see` annotation that points to the corresponding operation of `EntityManager`.
It's similarly clear what `@JPQL` does. On the other hand, perhaps we don't need it and all we need to do is give people explicit permission to put their JPQL in the `@Query` annotation. (I can see arguments both ways.)
Finally, if I recall correctly, at some stage someone (Otavio I guess) had proposed a built-in `JpaRepository`. I don't argue that we need it, but if you all still want it, it's completely trivial to define in terms of the annotations listed above.
So why is this now so easy when previously it was "hard". Well, before, we were trying to shoehorn JPA into the existing `@Save` annotation or whatever. But now that our model of lifecycle annotations is extensible, it's no longer hard.
Dunno. I guess I feel like it's now become a bit hard to justify _not_ doing it.
Reactions?
Contributor guide
Research direction
Start by reviewing the existing lifecycle-annotation model and the Jakarta Persistence EntityManager semantics referenced in the issue. Resolve the proposed scope, including the jakarta.data.orm package, @JPQL versus use of @Query, @SQL, and JpaRepository; done requires an agreed annotation set and defined behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, database
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100