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

Custom repository fragments do not work in fragment hierarchies [DATACMNS-1719] #2142

Closed
spring-projects-issues opened this issue May 7, 2020 · 3 comments
Assignees
Labels
status: declined

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented May 7, 2020

simonparadies opened DATACMNS-1719 and commented

We use repository fragments a lot to organise different aspects of repositories into logical chunks, mainly depending on which properties are queried (using interfaces as types).

I.e.

SpecializedDomainRepo inherits DomainRepo(Fragment)

DomainRepo(Fragment) inherits  BaseDomainRepo(Fragment)

BaseDomainRepo(Fragment) inherits  SpecializedQueryRepo(Fragment)

 

This has worked pretty well so far.

Now, in order to cope with more complicated query demands, we need to introduce customized methods.

However, as soon as the fragment with custom methods is inherited by another repo, e.g. if

package org.springframework.data.jpa.repository.sample;
public interface UserRepositoryChild extends UserRepository {}

is introduced (spring-data-jpa master branch), context startup fails with

java.lang.IllegalArgumentException: Fragment implementation org.springframework.data.jpa.repository.sample.UserRepositoryImpl does not implement org.springframework.data.jpa.repository.sample.UserRepository!java.lang.IllegalArgumentException: Fragment implementation org.springframework.data.jpa.repository.sample.UserRepositoryImpl does not implement org.springframework.data.jpa.repository.sample.UserRepository! at org.springframework.beans.factory.support.ConstructorResolver.instantiate

When introducing a @NoRepositoryBean Anntoation at UserRepository, the error becomes

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'userRepositoryChild' defined in org.springframework.data.jpa.repository.sample.UserRepositoryChild defined in : Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: Failed to create query for method public abstract void org.springframework.data.jpa.repository.sample.UserRepositoryCustom.findByOverrridingMethod()! No property overrridingMethod found for type User!

This does not happen when inheriting fragments without custom methods, e.g.

package org.springframework.data.jpa.repository.sample;
public interface SiteRepositoryChild extends SiteRepository {}

 

Is this a bug and is there a way around it (except flattening our inheritance hierarchy)? Thanks!

 


Affects: 2.3 RC2 (Neumann)

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented May 7, 2020

simonparadies commented

Sorry, this should have been created at Spring Data JPA. Is there a way to migrate it?

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented May 7, 2020

Oliver Drotbohm commented

Thanks for reporting this. I think it's fine in SD Commons as all the fragment handling code is living here

@mp911de
Copy link
Member

@mp911de mp911de commented Jan 26, 2021

@simonparadies repository fragments are discovered by name (<fragment interface name> + <impl-suffix>, typically FooImpl if the fragment interface is Foo). Hence a fragment is required to implement its fragment interface. Additionally, fragments are discovered only from the actual repository interface declaration. Any super-interfaces are not considered for fragment scanning as that would introduce additional scanning complexity and the problem of method precedence.

From a single repository (UserRepository extends Repository<…>, MyFragment1, MyFragment2), we can reason about fragment precedence. Problems arise when we would inspect super interfaces (MyFragment1 extends Foo, Bar, MyFragment extends Bar, Foo). Are Foo and Bar fragments? Which one has precedence and so on.

So besides recursive component scans, we would end up with another set of problems that apply only in very specific cases.

That being said, single-level fragment scans work as intended.

@mp911de mp911de closed this as completed Jan 26, 2021
@mp911de mp911de assigned mp911de and unassigned odrotbohm Jan 26, 2021
@mp911de mp911de added status: declined and removed in: repository type: bug labels Jan 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined
Projects
None yet
Development

No branches or pull requests

3 participants