jakartaee / jakartaee/data

[Use Case]: Annotations for use with Jakarta Persistence

Open
#470 13 comments 1 reaction 0 assignees View on GitHub
complete except for TCK enhancement
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.