Issue/datacmns 766 #144
Closed
Issue/datacmns 766 #144
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Not merged as per reasoning in DATACMNS-766. |
Aloren
pushed a commit
to Aloren/spring-data-commons
that referenced
this pull request
Jun 20, 2019
…int-id Make sure we copy variables to new InfoEndpoint
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
DO NOT MERGE - REVIEW REQUEST
@olivergierke @thomasdarimont I have run into a situation where someone wants to wrap a custom repository with Spring Data REST. The "real" backend is a SOAP interface, but I coded an experiment where I just use a
Map<ID, T>. I found that by coding a custom Implementation (as shown here for demo purposes), Spring Data REST works with it perfectly. Unfortunately, custom finders (like this) are not listed underneath Spring Data REST's /search path as a custom finder because of this explicit check forisCustomMethod().This PR shows me removing that one restriction. Upon building and deployment to my own local maven repository, my demo app that I linked to up above listed my custom finder and invoked it properly, so it looks like a good fix. What I cannot discern is other impacts. Basically, why was this restriction coded in the first place? Something else to test and verify? And seeing that this change didn't break any test cases, I am wondering what test case to write to verify it.
Thanks.