Add support to repository pattern

[rhuan080]

Hi all,

The repository pattern is a well-used and well-known pattern that facilitates querying data in an easy way. I think it matches the Cloud Native practices, as many Cloud Native applications have been built using this pattern. My suggestion is to add support to the repository pattern as it will improve the developer's experience and close the JPA to modern practices. Another argument is the Jakarta NoSQL is implementing this pattern as well, as you can see here. Adding it to the JPA will make the Jakarta EE API more harmonic, as both persistence APIs will provide a way to use this pattern.

[andyjefferson]

Define "add support". JPA is an API. What is your proposed API?

What some proprietary implementation software (that doesn't implement JPA) uses is not of much relevance here.

[m-reza-rahman]

I think this is about standardizing DeltaSpike Data/Spring Data JPA. An argument can be made that these things are mature enough to standardize now.

Reza Rahman Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

[rhuan080]

Hi @andyjefferson,

Define "add support". JPA is an API. What is your proposed API? Yes, I know! My proposal here is to add the repository pattern as a feature to JPA, to standardize it. As @m-reza-rahman said, DeltaSpike and Spring Data JPA already provide it, and is mature enough to standardize. The Jakarta NoSQL will provide this feature as well, as you can see here.

Thank you @m-reza-rahman , for helping me to clarify the proposal.

[hantsy]

Spring Data JPA itself supports CDI 1.0. But if you change the discovery type to annotated in CDI 2, it will not work, I filed an issue about this, but the Spring Data team does not want to fix this.

And the Repository pattern is more like an application-level design pattern to resolve real-world problems. I think this should be part of work like a tooling framework, eg. Apache DeltaSpike, or some other project led by Jakarta EE/Apache.

Like the Spring core framework, it also does not provide a repository pattern but makes all components work seamlessly.

And by the way, some good integration parts of the Jakarta EE in the Apache DeltaSpike should be considered to standardize to Jakarta EE spec, esp. the enhancements of CDI/Servlet environment.

• Simplify JPA in a CDI SE or Servlet/CDI container, eg. support injection of EntityManger automatically etc.
• Make @Transactional works outside a JTA environment, support JPA resource_local, etc.
• ...

In one word, make CDI more competent to Spring core framework in none full profile container, esp. a Servlet Container like Tomcat, Jetty etc, even a CDI SE with embedded tomcat and Jetty(I really hope there is a project led by Eclipse to do this, make it work like Spring Boot, a CDI bootable Application class which can run on the embeed Tomcat, Eclipse Jetty, Wildlfy-embedded, payara-embeed, openliberty fatjar etc).

[gavinking]

I do not believe that this functionality belongs in JPA, and I think it would be very inappropriate to add it to the spec.

[m-reza-rahman]

Hi Gavin, is it OK to ask for a bit more explanation on why this should not be a part of the specification? Is it merely too early or is there some other more fundamental issue?

[gavinking]

Because:

1. Different implementations of the DAO/repository/active record pattern have completely different APIs. Compare, for example, Spring Data JPA vs Panache. They look utterly different.
2. This exists as a whole separate layer to JPA. Even if it were worth doing (I don't think it is), it still wouldn't belong in the JPA spec.

This is something where different people should be free to do things according to the pattern they prefer. (In my case, I prefer to use a bare EntityManager.)

I would not want the JPA process to get bogged down into a fight between people who like Spring repositories (the "DAO" pattern) vs. people who prefer the "active record" style used by Panache and other things.

[m-reza-rahman]

Understood and makes sense. I appreciate your explaining further!

[Tibor17]

Spring F. 6 already implements Jakarta API and Spring awaits for Jakarta 10 https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6

So I would suggest to prepare a separate PR and let us know about the entire process when a new feature including TCK is involved.

It is wrong question whether EM would survive. It will but here I am talking about marketing and the ability to sell the Jakarta project. Currently the project is missing a lots of Cloud features athat are in Microprofile and these Spring/Deltaspike Data.

[rhuan080]

The Jakarta EE has the Jakarta NoSQL coming, that is based on the JNoSQL that has the repository pattern as feature.

On Sat, Nov 20, 2021, 23:10 Tibor Digana @.***> wrote:

Spring F. 6 already implements Jakarta API and Spring awaits for Jakarta 10

https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6

So I would suggest to prepare a separate PR and let us know about the entire process when a new feature including TCK is involved.

It is wrong question whether EM would survive. It will but here I am talking about marketing and the ability to sell the Jakarta project. Currently the project is missing a lots of Cloud features athat are in Microprofile and these Spring/Deltaspike Data.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/eclipse-ee4j/jpa-api/issues/294#issuecomment-974743025, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACN424CZM3GDQIH5HYP55HDUNBIJDANCNFSM4SPCWVWA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[m-reza-rahman]

I think a good approach is working with the DeltaSpike Data folks and get the project donated to Jakarta Persistence as an optional module. Otherwise, I suspect there isn't resources/interest to implement this.

[hantsy]

Quarkus, Micronaut, Spring Data have their own Repository, it is difficult unite them use a Repository spec. Leave the tools/framework to implement it themselves.

[hantsy]

And the Eclipse EE4j really want to handle something like this, pickup the existing Apache DeltaSpike and release it as a side project to Jakarta EE spec.

[tandraschko]

+1 in general provide such a functionality in EE4J

im not the initial creator of DeltaSpike Data but i maintain it since years and i can provide help here

since years, features of DeltaSpike becomes standardized in JakartaEE and we should continue

however, it does not make sense to just rename org.deltaspike.data to org.eclipse.ee4j.someothername.data if its not a official spec part, it will be just a "XXX Data" again also i think we should check all products (Spring, DeltaSpike, Blaze) and build a new spec based on them

[Tibor17]

NoSql is totally different story. It is not safe to share one annotation in two APIs. One day it would be inconsistent.

Dňa ne 21. 11. 2021, 3:14 Rhuan Rocha @.***> napísal(a):

The Jakarta EE has the Jakarta NoSQL coming, that is based on the JNoSQL that has the repository pattern as feature.

On Sat, Nov 20, 2021, 23:10 Tibor Digana @.***> wrote:

Spring F. 6 already implements Jakarta API and Spring awaits for Jakarta 10

https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6

So I would suggest to prepare a separate PR and let us know about the entire process when a new feature including TCK is involved.

It is wrong question whether EM would survive. It will but here I am talking about marketing and the ability to sell the Jakarta project. Currently the project is missing a lots of Cloud features athat are in Microprofile and these Spring/Deltaspike Data.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/eclipse-ee4j/jpa-api/issues/294#issuecomment-974743025 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/ACN424CZM3GDQIH5HYP55HDUNBIJDANCNFSM4SPCWVWA

. Triage notifications on the go with GitHub Mobile for iOS < https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android < https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/eclipse-ee4j/jpa-api/issues/294#issuecomment-974743393, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH7ER6TUG37UIXPSW7H3NDUNBIYPANCNFSM4SPCWVWA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[m-reza-rahman]

@lukasj, @m0mus what are your thoughts on moving this work item forward? Perhaps @tandraschko's willingness to help is a game changer on this one? Would it make things easier if this was done as an optional ("incubation") module to start with? This could avoid contention with other approaches to solving the same problem. To be honest though I really do believe that the DeltaSpike Data/Spring Data JPA approach is the de-facto standard that is unlikely to change any time soon.

[markus-ruderman]

I see the DeltaSpike Data and Spring Data as de-facto standard too. Mainly every developer comes in touch today with one of the solutions at their work. I use DeltaSpike Data already since years in my projects at work and it would be awesome when we can get in near future a standardized Jakarta EE API for that based on an existing library 😃👍

[tandraschko]

I could definitely prepare/extract the code for a official POC API + RI as first step But we would also need to make @Transactional to work with resourcelocal

[phillipross]

@hantsy I'm curious to know some of the details about what you consider to be difficult about an api/spec that would cover some of the projects that you mentioned.

[phillipross]

@tandraschko I'm curious to know your thoughts on the potential for deltaspike data to be adapted/evolved to also handle non-JPA persistence. It seems like many projects/frameworks have been mentioned in this issue, as well as the nosql spec, many of which already implement repository data access pattern (and/or active record), but I was wondering about the potential to have a unifying api. It'd be wonderful to avoid similar historical situations that existed with things like dependency injection, where we had multiple specs/apis for doing similar things.

[m-reza-rahman]

Looping in @otaviojava to comment from a Jakarta NoSQL perspective. A unified repository layer is potentially worth exploring. Otavio should have valuable insights to offer.

[don4rolex]

I think out of the box support for repository pattern will be a great development to further modernize the EE framework.

It will be more standardized and easier to set up and use There will also be a lot more support for frameworks like DeltaSpike if it is adopted.

It will just work out of the box and won't require some hard wiring and work arounds or feel like trying to stitch things together.

[keilw]

@markus-ruderman Together with @otaviojava and @teobais I gave presentations about persistence frameworks with a NoSQL focus and I agree about Spring Data being the de-facto standard so far but I honestly never heard of DeltaSpike Data nor anyone using it. There are plenty of others Micronaut Data maybe Panache although not all of them make unified use of patterns like the Repository pattern etc. in ways Jakarta NoSQL or Spring Data do.

Given there is already one Jakarta EE spec it would be short-sighted to reinvent the wheel, but what we see with Jakarta Commons already proposed there could be room for this in such a new spec or if it was too data specific then "Jakarta Data" or "Jakarta Persistence Common" or similar but not twice in Jakarta NoSQL and the existing Persistence API.

[hantsy]

I could definitely prepare/extract the code for a official POC API + RI as first step But we would also need to make @transactional to work with resourcelocal

I really like this feature, mentioned in https://github.com/eclipse-ee4j/jpa-api/issues/294#issuecomment-821767078

I have created an issue on JTA for this, https://github.com/eclipse-ee4j/jta-api/issues/190, I hope we extract transaction work from Apache DeltaSpike to JTA, make it work in a none-JTA and Servlet/CDI environment.

[hantsy]

@hantsy I'm curious to know some of the details about what you consider to be difficult about an api/spec that would cover some of the projects that you mentioned.

1. DeltaSpike Data, Spring Data handles the query facilities such as derived queries, etc, at runtime time (proxy), but Quakrus, Micronaut Data process them at compile time.
2. The content of Repository interface itself it not easy to satisfy all users and all cases(blocking, none blocking, reactivestreams, etc.).
3. We should unite this Repository with JNoSQL Repository?

[m0mus]

Although the repository is a nice addon to JPA, I don't think it should be a part of JPA spec. I see a problem in updating existing implementations (EclipseLink, Hibernate, OpenJPA) to support it. IMHO it should be a separate stand-alone specification which relies on JPA for ORM. Recently we discussed adding a new data-related specification to MicroProfile and it was supported by MP WG members. It's a part of 2022 Program Plan. You (someone who wants to drive it) can propose it there. Alternatively, you can make a proposal to Jakarta EE (if you want to have jakarta namespace support since the beginning). The choice is yours. Whatever you chose, you should create a project presentation and bringing it to one of Jakarta Platform meeting or to MP Technical Meeting for review and feedback.

[phillipross]

1. DeltaSpike Data, Spring Data handles the query facilities such as derived queries, etc, at runtime time (proxy), but Quakrus, Micronaut Data process them at compile time.
2. The content of Repository interface itself it not easy to satisfy all users and all cases(blocking, none blocking, reactivestreams, etc.).
3. We should unite this Repository with JNoSQL Repository?

@hantsy thanks for taking the time to enumerate some of these. All good points.

In the case of 1 and 2, it seems like there's a question of "is it worth the effort?" in terms of establishing some common specification to serve as an abstraction for how these frameworks provide data access.

In the case of 3, I think @keilw mentioned factoring out data access into a spec separate from nosql (at least that's how I interpreted his comments).

Quick conclusion: there's a lot to analyze and think about 😉 thanks again!

[tandraschko]

i think, if we should really introduce something like a repository API, we MUST NOT just do it for JPA.

We have to check if we can really create a API for all Sql, NoSql or even custom datasources. I think its quite simpel for basic cases like:

@Repository
public interface PersonRepository extends EntityRepository<Person, Long>
{
    List<Person> findByAgeBetweenAndGender(int minAge, int maxAge, Gender gender);
}

But what about something like JPA QueryHints or other stuff? Maybe we can do a basic API for all datasources and provide also extended API artifacts for JPA built-in

[otaviojava]

I enjoy anything that makes JPA update and easier to use for the Java Developers. Currently, almost all the JPA solutions have this Repository interface approach, such as Quarkus, Spring Data, Apache Delta Spike, etc.

So, it is really relevant to Java Developers.

I'm not sure about a new specification to hold a single interface.

IMHO: it makes more sense to have the Repository interface in JPA as we have on Jakarta NoSQL.

[keilw]

@m0mus Thanks for the heads-up. Looking at all the challenges to get DeltaSpike Config > Tamaya > Config JSR > MP Config now into its 5th regeneration (almost more than Doctor Who! ;-) as Jakarta Config, I would feel more comfortable if this happened in a Jakarta "Whatever" spec instead of taking a detour via MP. Some other more "exotic" things like binding to yet another CNCF project seems fine at MicroProfile as a "pseudostandard" but this looks far more generic to me. Plus another Jakarta spec already applied it, so as @otaviojava said (but I agree with others here it probably should not be in JPA itself but a common spec usable by others) probably better keep it in Jakarta EE.