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

Provide means to expose custom repository methods [DATAREST-206] #588

Open
spring-projects-issues opened this issue Dec 13, 2013 · 11 comments
Open
Assignees
Labels

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Dec 13, 2013

Aaron Loes opened DATAREST-206 and commented

i have custom methods in my repository and interface that are not showing up in my search links ... no search link at all. I believe the line at fault is in DefaultRepositoryInformation#isQueryMethodCandidate

private boolean isQueryMethodCandidate(Method method) {
	return isQueryAnnotationPresentOn(method) || !isCustomMethod(method) && !isBaseClassMethod(method);
}

i would think that if a method is a custom method (defined in interface and implementing class but is NOT a method in the base repository class, then it should be a candidate for a query method. So shouldn't the method be as such?

private boolean isQueryMethodCandidate(Method method) {
	return isQueryAnnotationPresentOn(method) || isCustomMethod(method) && !isBaseClassMethod(method);
}

Affects: 2.0 M1 (Codd)

Issue Links:

  • DATAREST-850 Return custom methos if enables
    ("is duplicated by")

  • DATAREST-158 Exposing custom repositories
    ("is duplicated by")

  • DATAREST-469 Introduce dedicated resource type for search links

  • DATACMNS-584 Don't resolve query for custom methods that are annotated by @Query

17 votes, 22 watchers

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Dec 13, 2013

Oliver Drotbohm commented

This is by design. Custom repository methods are no query methods as they can effectively implement any behavior. Thus, it's currently impossible for us to decide about the HTTP method to expose the method under. POST would be the safest option but that's not in line with the generic query methods (which receive GET).

I'll turn this into an improvement as I can imagine us providing means to express the intended HTTP method either through an annotation or external configuration

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Dec 13, 2013

Aaron Loes commented

i guess a more generic question is how do i get the search links to appear? I'm not seeing specifics of how to get search links to work but am seeing examples in documentation.

see http://docs.spring.io/spring-data/rest/docs/2.0.0.M1/reference/htmlsingle/

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Feb 12, 2014

Aaron Loes commented

added comments, please review (didn't know i needed to explicitly use the "provide feedback" button)

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jun 17, 2014

Sri commented

Could we leverage @RequestMapping annotation for custom methods and appropriately expose the methods as HTTP GET or POST?

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Oct 26, 2014

Jan Durian commented

+1. This is my most desired feature. A lot of queries in our project are just complex and must be implemented as custom repository methods with related boilerplate code (controllers etc.). For this purpose I would suggest to create new category, something like a 'custom repository query' methods. Just annotated custom methods with @Query or so. Then these could be validated and exposed same way as current query/search methods.

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Nov 13, 2014

Jeffrey Segal commented

I agree with the previous commenters on the usefulness of this feature. The workaround of creating your own controller is certainly reasonable but less elegant than letting spring-data-rest do that for you. That said, I concede that a lot of explicit information would need to be provided in the form of method annotations for the framework to be able to properly determine HTTP methods, return codes and error conditions

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jan 27, 2015

Jimmy Miller commented

I understand why these aren't exported by default and the discussion around how to export them. In the mean time though, if we want to add our own links to the /search section, how should we go about doing that?

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jan 27, 2015

Oliver Drotbohm commented

I created DATAREST-469 to create a special type to be returned for the search resource so that you can write a ResourceProcessor<SearchLinksResource> to add links to it. Scheduled for the Evans SR2 release due tomorrow

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 2, 2015

Frederik Dejaeghere commented

Why not by naming convention? Methods starting with find.... -> GET, etc

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Sep 8, 2015

Anton Koscejev commented

Perhaps methods annotated with @org.springframework.data.jpa.repository.Modifying could be exposed as POST by default

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jun 22, 2018

Guram Savinov commented

ResourceProcessor<SearchLinksResource> still has disadvantage: it doesn't add link to profile of resource.

Why don't you make it possible by adding some special annotation. so users can mark custom repository methods to expose links?

It's pain for many people and forces to write a lot of boilerplate code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants