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.

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

Ebean-Data (auto generated repositories)? #3400

Open
magicprinc opened this issue May 13, 2024 · 1 comment
Open

Ebean-Data (auto generated repositories)? #3400

magicprinc opened this issue May 13, 2024 · 1 comment

Comments

@magicprinc
Copy link

magicprinc commented May 13, 2024

Ebean is a great project and has almost everything one needs or wants.
The only advantage of Spring Data JPA left is its auto-generated repositories (The programmer declares an interface, and Spring Data generates the implementation according to the meaning hidden in the method name. IDEA helps to write such names).
What do you think about this Spring Data feature?
Do you have any plans to support this?

PS: Quarkus has implemented part of it, to help migrate from Spring (google: Quarkus spring data JPA).
BTW, It is a good idea to test (to fix, create extension) and advertise Ebean's compatibility with Quarkus. Many people are tired of Spring and are trying to escape.
As start: https://github.com/smallrye/jandex
And another idea: Quarkus Panache could have some ideas worth to borrow (just impromptu, no practical experience with Panache)

PPS: I mean: query creation from method names.

public interface UserRepository extends Repository<User, Long> {
  List<User> findByEmailAddressAndLastname(String emailAddress, String lastName);
  List<Employees> findFirst5ByFirstNameStartsWithOrderByFirstName(String firstNameStartsWith);
}

PPPS: I am not sure, if it is actually a good thing:
Too much magic and syntactic sugar are bad for the health :-)

@rbygrave
Copy link
Member

What do you think about this Spring Data feature?

I personally have never liked this feature. The 2 main reasons being that:

  • It omits the "only select what you need" / "optimise the projection" aspect of a query and pretty much promotes the "select everything on the root bean + lazy load as necessary" instead. In general there are a lot of query options like locking, non-trivial predicates, conditional predicates, L2 cache etc and I don't think this approach deals with any of those query options nicely.
  • It works for simple queries but gets ugly for anything beyond that. It terms of a "sweet spot" it has a narrow "sweet spot" and then when you hit the point that you want more control over the query you are faced with having to completely change the technique being used. As a Dev you are working along using this and then you hit a wall and have to completely change the approach - it isn't a smooth graduated approach that works from the simplest query to the most interesting query.

Do you have any plans to support this?

No I don't. I do know that a lot of people really like it but those people also don't know about query beans.

Quarkus Panache could have some ideas worth to borrow

Yes, although I think we've already done that (or they've copied a feature we already had). One thing we don't talk about is that ebean has the mode where we can just use public fields on entity beans (omit getters and setters) and ebean enhancement will automatically modify that field access to method access and get full normal functionality in terms of lazy loading and dirty checking etc.

I don't think there is anything outstanding I saw in Panache that we desire but I'll have another look some day in case they have added something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants