Improve parser for derived queries so properties starting with "is" become usable. [DATACMNS-1761]

[spring-projects-issues]

Hayk Avetisyan opened DATACMNS-1761 and commented

Given the following example entity:

@Entity
public class CountryNode {
   @Id
   @GeneratedValue(generator = "uuid2")
   @GenericGenerator(name = "uuid2", strategy = "uuid2")
   private UUID id;
   @OneToOne
   @JoinColumn(name = "country_id")
   private Country country;
}


@Entity public class Country {
   private String iso2;
}

When I create a Jpa Repository Function to find all entities by a property of the relation:

 

@Repository
public interface CountryNodeRepository extends JpaRepository<CountryNode, UUID> {
   List<CountryNode> findAllByCountryIso2(String countryIso2);
}

Then it doesn't work

(if it was findAllByCountryIno2, it would work)

—

It works for findAllByCountry_Iso2(String countryIso2). But this is not the desired way for cases where there is, for instance, a SonarQube rule that does not allow/recommend to use underscores in function names.

 

---

No further details from DATACMNS-1761

[spring-projects-issues]

Jens Schauder commented

Please clarify what you mean by "it doesn't work". Doesn't it compile? Does it throw an exception at start time or when calling the method? Or do you get wrong results?

A reproducer would definitely help.

[spring-projects-issues]

Hayk Avetisyan commented

I use it in a Spring boot application, and it just does not run. The compile process is exited without any error. So, the application does not run. Spring Data "understands" the function as "country is o2". I understand that this is a complex issue

[spring-projects-issues]

Hayk Avetisyan commented

But because there are limited possible combinations in an SQL statement where you use the word "is" (such as "IS NOT" or "IS NULL"), I thought this could be considered as a bug and be solved that way. I mean to check if there is no "NOT" or "NULL" after "IS" then it is a column name

[spring-projects-issues]

Mark Paluch commented

We should investigate whether we can identify a property first before falling back to the Is keyword in PartTree