RepositoryResourceMapping Should Work With Repositories Instead Of PersistentEntities

[ptahchiev]

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]

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.

[ptahchiev]

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.

[ptahchiev]

Hello, is there any update on this?