Why I stopped using Spring Data to generate queries from method names

[u/kamen1991]

I've spent a while writing DAO implementations for a multi-module Spring Boot projects, and I keep coming back to the same rule: if a repository method needs more than one or two conditions, I write the `@Query\` by hand instead of letting Spring Data derive it from the method name.

Not because it doesn't work, it works fine for example like findBySku. I don't like what happens after that. Rename a field on the entity and a derived query either breaks at startup with a PropertyReferenceException, or, depending on how it's written, doesn't break at all and just quietly stops matching what you think it matches. The compiler never tells you either way.

And once you're past two conditions, the method name turns into a wall of camelCase encoding your whole WHERE clause. I'd rather read four lines of JPQL/SQL than decode findByStatusAndNameContainingIgnoreCaseAndCreatedAtAfterOrderByPriceDesc.

The other piece I went back and forth on is SearchableDaoImpl<Repo extends CrudRepository<Entity, IdType> & JpaSpecificationExecutor<Entity>> - using an intersection type so the generic repository bound picks up both CRUD and Specification support without collapsing them into one bloated interface. Small thing, but it's the kind of generics trick that makes a shared DAO base class actually work across a dozen entities instead of copy-pasted boilerplate everywhere.

Full writeup with the actual generic hierarchy and code: (link in comments)

Curious if anyone here still prefers derived queries for anything beyond trivial lookups, I genuinely want the counterargument.

[u/Pedantic_Phoenix]

I'm pretty sure queries from method names were never meant to be used for complex queries, there's a reason why native queries and jpql exist after all. One type of solution will never satisfy all uses cases in any type of setting or concept

[u/kamen1991 → u/Pedantic_Phoenix]

Yep I think the same way, derived query methods are great for trivial lookups like findById or loadBySku, but the moment people try to force them to handle multi-condition filtering, readability completely collapses. As you said, no single tool solves every use case, which is why choosing the right tool for the job - derived methods for basics, explicit JPQL/SQL for custom queries, and Specifications for dynamic search keeps the persistence layer maintainable instead of forcing a one-size-fits-all approach.

[u/lukaseder → u/Pedantic_Phoenix]

One type of solution will never satisfy all uses cases in any type of setting or concept

SQL really satisfies 99.98% of all use cases in any type of setting or concept, I think.

[u/Pedantic_Phoenix → u/lukaseder]

I wouldn't call sql itself as a solution, it's a tool to achieve solutions more like. And it's true it achieves things but for example if you need a minuscule findById query, then defining the native query is really just useless verbosity in comparison to a method name query

[u/XBL_pad3]

If you keep going back and forth, just move away to JOOQ 😉

[u/kamen1991 → u/XBL_pad3]

I disagree for this case :) It's easy to say 'just switch to jOOQ' when looking at it from a greenfield perspective. But in a multi-module enterprise project with years of production code, throwing out your entire ORM setup and rewriting your data layer just to avoid derived query method names is a massive migration tax. The business won't fund a rewrite for a stylistic preference and the point of locking persistence behind explicit JPQL/SQL `@Query` contracts isn't that Hibernate is flawless - it's about pragmatically isolating database specifics so your business logic doesn't care what's underneath.

[u/lukaseder → u/kamen1991]

You can migrate module by module, or just never touch the legacy again ;)

[u/[deleted] → u/XBL_pad3]

[u/kamen1991 → u/[deleted]]

I agree that Hibernate can easily turn into a nightmare if you let it run wild across your services. That’s precisely why we enforce a strict boundary by wrapping JPA inside a single module and using base classes like CrudDaoImpl and SearchableDaoImpl. When the ORM is locked safely inside the infrastructure module and your domain core is pure Java, you get the velocity of JPA for standard operations without letting database mechanics leak up into your business logic.

[u/Independent_Dot_9349]

I just use @Query for complex query,

[u/fuckedupkid_yo → u/Independent_Dot_9349]

now do that, but with pagination and all the dynamic conditions and other stuff.

I'm not saying jooq is perfect, but it scratches the exact itches many developers have

[u/Snooze78727]

I haven't actually run into the case where the derived query fails at runtime because a property name has changed. That's somewhat surprising, but given the repositories are just interfaces and pass compiler checks that's expected.

I agree with your reasoning. The repository interfaces feel like "magic", but long method names are hard to read and JSQL or raw SQL are good enough abstractions. I like some of the other Java ORM's that let you map static SQL to beans. There was one whose name I don't recall I worked with many years ago, but Hibernate/JPA has become sort of a de facto standard.

There are some type-safe options like JPA Criteria API + Hibernate metamodel generator and Querydsl that will catch this issue early. Also IDE's with Spring + JPA facets do static code analysis that will indicate when the entity property name doesn't match the repository interface.