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

Allow users to provide custom UriToEntityConverter #2277

Open
wants to merge 1 commit into
base: 3.7.x
Choose a base branch
from

Conversation

ptahchiev
Copy link

  • You have read the Spring Data contribution guidelines.
  • You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
  • [-] You submit test cases (unit or integration tests) that back your changes.
  • [-] You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jun 24, 2023
@mp911de mp911de self-assigned this Jul 3, 2023
@mp911de
Copy link
Member

mp911de commented Jul 4, 2023

Care to elaborate what type of customization you're looking for the UriToEntityConverter as you want to use your own instance. I generally wonder whether it would make sense to define UriToEntityConverter as bean and look it up from there. Thoughts, @odrotbohm?

@ptahchiev
Copy link
Author

ptahchiev commented Jul 4, 2023

In my company we are extending hibernate and spring-data jpa so that we can build JPA entities as interfaces so that we can extend from multiple other interfaces. Thus a JPA entity looks something like this:

@Entity(CustomerEntityDefinition.NAME)
public interface CustomerEnttyDefinition extends AbstractNameable, AbstractDescriptionable, AbstractPicturable {
      String NAME = "user";
}

and the corresponding repository looks like this:

@Repository(value = CustomerRepository.NAME)
@RepositoryRestResource(itemResourceRel = CustomerEntityDefinition.NAME, path = CustomerEntityDefinition.NAME)
public interface CustomerRepository extends AbstractRepository<CustomerEntityDefinition, Long> {
    String NAME = "customerRepository";
}

We need a custom UriToEntityConverter because the one provided by spring-data works with PersistenEntities and ours work with Repositories. This issue is closely related to: #2276

As a general rule I view spring and the whole ecosystem as a framework that users should be allowed to extend and plug-into, not like a library that one is supposed to just use and not touch at all. It would be a nice idea if it a bean with a @ConditionalOnMissingBean annotation or some other way to allow users to change it if they need to.

@odrotbohm
Copy link
Member

I think we have to take a step back from suggesting changes to the implementation immediately and get on the same page what the problem is that we need to solve. I see a couple of fundamental issues with the suggested changes (as well for #2279).

  1. Repositories and PersistentEntities are entirely different concepts that are hardly related to each other. The former represents all repositories and allows accessing metadata about the aggregate types that are handled by those. The latter represents all entities known to the system. That's why we cannot simply exchange one for the other in classes that refer to PersistentEntities as they are likely to expect to see all types.
  2. Converter implementations becoming beans can significantly affect fundamental Framework functionality. Especially if the converters make quite strong assumptions about the source values, such as, in case of UriToEntityConverter, the URIs handled. The converter is not a general purpose one to convert from URI to identifier types (e.g. Long). That's why we also do not register them in the global ConversionService but rather create our own one, so that we can control which Converters are registered and in which context that particularly configured instance gets used. Registering UTEC as a bean would make it get applied globally in a Spring Boot context, which is likely to create havoc.
  3. We moved off RepositoryRestMvcConfiguration as primary vehicle for extension years ago.

I would like to start with a outside-in sample project that shows what's intended to work from a user application perspective to showcase what exactly is not working as expected. We can then debate how to best approach the problem.

@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
@mp911de mp911de assigned odrotbohm and unassigned mp911de Jul 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-feedback We need additional information before we can continue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants