A way to shorten/alias method name derived queries. [DATACMNS-1213]

[spring-projects-issues]

justin mccune opened DATACMNS-1213 and commented

Many think that it's great to use the name of the method to infer the SQL for a query on a repository. However, often the use of descriptive field names and one or two concerns (an AND operation with a SORT ordering) leads to incredibly long (or "ugly" names). For example one properly named long field and a simple boolean & sort order lead to the repository method name being 96 characters long. This destroys many style guides line-lengths when used.

While it is an alternative to use @Query make a shorter method name and write the actual query by hand, or to use java's "default" on interface to alias a shorter form that uses the full / ugly query. They both are not as elegant as the simplicity of the named query where preferably I alias it.

Often the alias / shorter name is just as meaningful and clear in meaning even if omitting implicit/assumed context-- see examples below.

This has come up several times with coworkers (in multiple companies) & a quick search has shown that others have the same concern.

https://stackoverflow.com/questions/30019408/how-to-shorten-names-of-query-methods-in-spring-data-jpa-repositories

When I read the above, I thought perhaps I'd found the solution-- but it was a suggestion that I couldn't find in the Spring Data feature request list, so I thought I'd add it.

So what I'd like would be something like the below-- where the annotation name is used instead of the actual method name to build the query.

@QueryByMethodName("findOneByDeletedIsFalseAndEmail")
User findOneByEmail(String email);

@QueryByMethodName("findOneByReallyLongFieldNameAndActiveStatusIsTrue")
Entity findOneByRLFN(ReallyLongFieldNameType value)

This improves both simplicity and readability. And I'm not particular about the annotation name.

---

16 votes, 8 watchers

[gbraleigh]

Yes, please! This seems like a relatively simple feature that would be very valuable, improving our ability to read and easily understand repository generated method names.

[kadirtn]

Method name gets too crowd just for a simple query, proposed approach seems convenient.

[laguiar]

any news on this proposal?

[grzechup]

I would love to see this feature. For example, I have the following method query in my repository.
Optional<CallManagerMonitoredUser> findByServiceProviderBwIdAndGroupBwIdAndUserBwIdAndMonitoredContactContactNameAndMonitoredContactContactNumber(String serviceProviderId, String groupId, String userBwId, String contactName, String contactNumber);
That will add much readability to my code.

[bektun]

if you extend your repository with JpaRepository then you can use a default method which calls your origin repository method:
public interface UserRepository extens JpaRepositry<String, User> {
List<User> findUserByCreatedDateAndHairColorAndFavoriteTeamAndBLaBla(param1, param2...);

default findBlaBlaUser(param1, param2...) {

return findUserByCreatedDateAndHairColorAndFavoriteTeamAndBLaBla(param1, param2...);
}
}

in your service you can now call myUserRepo.findBlaBlaUser(param1, param2...)

[grzechup]

if you extend your repository with JpaRepository then you can use a default method which calls your origin repository method: public interface UserRepository extens JpaRepositry<String, User> { List<User> findUserByCreatedDateAndHairColorAndFavoriteTeamAndBLaBla(param1, param2...);

default findBlaBlaUser(param1, param2...) {

return findUserByCreatedDateAndHairColorAndFavoriteTeamAndBLaBla(param1, param2...); } }

in your service you can now call myUserRepo.findBlaBlaUser(param1, param2...)

Yeah you can use this trick but still, it isn't pleasant when you enter your repository and see your long basic methods.

[mp911de]

Spring Data is not in charge of defining yet another query language. We've built query derivation to allow users conveniently declare simple queries without having to dive into the store-specific query language to implement common use cases.
If a method becomes too long, then it no longer fits the intended usage pattern, and it falls out of this category.

Putting the potential String into an annotation moves the problem from the method declaration to an annotation. Still, it doesn't cure the underlying problem of fixing a query that is too complex. If it is complex, then it needs to be expressed that way or be addressed using the store's query language; We recommend either using @Query or a custom implementation.

Furthermore, we are strictly against putting code into annotations that actually belong somewhere else. Such a change leads to removing information from the call site. The method name becomes less expressive at its best. In the worst case, it contradicts what was specified in an annotation.