CodeSOD: Longer Isn't Better

Andrew H writes "this is an interface for one of our Spring Data repositories". If you've ever looked at Spring's documentation, you know the punchline. Spring has certain naming conventions that have become a notorious.

Spring Data is an ORM, and among other things, it allows you to design interfaces which are translated into a series of queries based on the naming conventions. So, for example, a method named findDistinctByTenantId would turn into a query in the database. It's a useful convenience for simple CRUD operations, but for more complex queries, you're still better off writing your SQL in an @Query annotation. SQL is still the best way to build complicated RDBMS queries.

That doesn't mean you have to use SQL. Andrew's co-worker provided this method:

public Page<Ad> findDistinctByTenantIdAndTitleIgnoreCaseContainingAndFlagsNotNullAndFlagsResolutionTypeValueOrTenantIdAndDescriptionIgnoreCaseContainingAndFlagsNotNullAndFlagsResolutionTypeValueOrTenantIdAndEmailIgnoreCaseContainingAndFlagsNotNullAndFlagsResolutionTypeValueOrTenantIdAndContactNameIgnoreCaseContainingAndFlagsNotNullAndFlagsResolutionTypeValue(Long tenantId, String title, String resolutionTypeValue, Long tenantId2, String description, String resolutionTypeValue2, Long tenantId3, String email, String resolutionTypeValue3, Long tenantId4, String contactName, String resolutionTypeValue4, Pageable pageable);

As an aside, this convention doesn't let you reuse a parameter in multiple conditions, so those multiple tenantId, tenantId2, etc. parameters? They all need to get the same value. Ditto on all the resolutionTypeValue parameters. This may not be the longest method name ever, but it's certainly a strong contender.

[Advertisement] Continuously monitor your servers for configuration changes, and report when there's configuration drift. Get started with Otter today!