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

RepositoryResourceMapping Should Work With Repositories Instead Of PersistentEntities #2276

Open
ptahchiev opened this issue Jun 23, 2023 · 3 comments
Assignees
Labels
status: feedback-provided Feedback has been provided

Comments

@ptahchiev
Copy link

Hello,

up until version 3.3.9 the RepositoryResourceMappings class was using the Repositories object to populate the cache needed for the ResourceMetadataHandlerMethodArgumentResolver as you can see here:

https://github.com/spring-projects/spring-data-rest/blob/3.3.9.RELEASE/spring-data-rest-core/src/main/java/org/springframework/data/rest/core/mapping/RepositoryResourceMappings.java#L69

Then this method was changed to use the PersistentEntities as youc an see here:

https://github.com/spring-projects/spring-data-rest/blob/main/spring-data-rest-core/src/main/java/org/springframework/data/rest/core/mapping/RepositoryResourceMappings.java#L69

The PersistentEntities object is constructed by trying to locate all the javax.persistence.metamodel.Metamodel and thus completely ignores the alternativeDomainTypes a RepositoryMetadata may hold.

@odrotbohm
Copy link
Member

I don't think your suggested PR maintains the current semantics of the code. PersistentEntities contains all entities not only the aggregate types declared in repository interfaces. The commit 940a676 that changed the code to PersistentEntities actually explains the rationale for the change in detail.

Similarly to what I described [here|https://github.com//pull/2277#issuecomment-1621464781], I'd like to take a step back, see a sample project that shows what is not working as expected and take it from there. Alternatively, adding a test case to the SD REST codebase showing what's not working would work as well.

@odrotbohm odrotbohm added status: waiting-for-feedback We need additional information before we can continue and removed status: waiting-for-triage An issue we've not yet triaged labels Jul 5, 2023
@ptahchiev
Copy link
Author

Hello Oli,

I managed to create a simple project that reproduces the behaviour. It is here:

https://github.com/ptahchiev/spring-data-rest-2279

Before you run it here's a little bit of context.
My company has created a platform for business application development. We have a marketplace with more than 160 modules and each module (jar, dependency) contains something we call EntityDefinition - it is an interface that can contrbute a number of properties to an existing entity. For example:

  • commerce module contains ProductEntityDefinition interface
  • promotion module contains PromotionableProductEntityDefinition interface
  • review module contains ReviewableProductEntityDefinition interface
  • .....more modules.

Then the user adds a bunch of modules they need in their pom.xml and compiles. Only now, at compile time, we create an entity CLASS that implements all the interfaces that are in the classpath (for example if the user added all three dependencies from above we will generate):

public class ProductEntity implements ProductEntityDefinition, PromotionableProductEntityDefinition, ReviewableProductEntityDefinition {

So that is the reason why we need to extend spring-data to make the repositories work with JPA entities that are interfaces, and not classes.

In the sample project above you will find:

  • CustomRepositoryMetadata - we declare our own repository metadata so that we can find the domain class based on the entity definition interface. In our real product we build a key-value index at compile time, but here I have hardcoded the only one entty that I have in my project
  • DemoJpaRepositoryFactory - we need this in order to provide our custom repository metadata.

We also support QueryDSL and for that reason i also need to provide a custom UriToEntityConverter but i've left this out for now.

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Jul 11, 2023
@ptahchiev
Copy link
Author

Hello, is there any update on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: feedback-provided Feedback has been provided
Projects
None yet
Development

No branches or pull requests

3 participants