spring-projects
Support `java.util.Pattern` for `LIKE` query method predicates
@qkrtkdwns3410 spring-projects/spring-data-jpa#4109 isn't really addressing what this ticket has been about. Frankly, the ticket has no description so one can easily fill that void with any interpretation, such as you did by employing AI to come up with something.
Instead, we want merely call out in our documentation that particular Spring Data modules accept Pattern for the Like keyword (in a similar way that we do for Matches and Regex keywords).
@mp911de I’m sorry, I thought you meant to change it so that patterns could be used with the LIKE operator. i`ll close that pr soon.
I want to confirm if my understanding is correct:
The issue content is empty, which can lead to misunderstandings.
I am curious if the statement implies that the corresponding code was written by an AI and is of poor quality.
Does the tag "ai-slop" mean that?
The issue content is empty, which can lead to misunderstandings.
Internally, we sometimes create tickets as a reminder or follow-up to prior discussions, assuming that we will address them ourselves shortly thereafter. In such cases, we do not always capture the necessary context in the ticket itself.
I am curious if the statement implies that the corresponding code was written by an AI and is of poor quality. Does the tag "ai-slop" mean that?
AI LLM's are content-generators that sometimes may generate what we were presumably looking for. Much more often their output leads rather to frustration.
The submitted pull request spring-projects/spring-data-jpa#4109 contains a lengthy description of the mechanical changes repeating itself but does not explain why introducing Pattern would be an improvement over the current design. The statistics-nature of LLM makes up grammatically correct sentences from random words that look as if it was useful information:
providing a more intuitive and type-safe way to define LIKE
It lacks a substantiated argument. At the same time, the proposed change silently strips anchors and introduces a partial-regex API surface that looks more capable than it actually is. Such a change creates expectations that cannot be met and can surprise users who assume broader regex support or rely on features that some databases already implement natively. An API implying full regex semantics, but failing at runtime for non-trivial expressions asks for all sorts of trouble. That is not a direction we can take lightly.
This also intersects with a broader concern: LLM-generated code based on minimal issue descriptions tends to lack the necessary depth regarding design, compatibility, and long-term maintenance. Questions around licensing of model training data remain unresolved as well.
Submitting AI-generated changes without careful technical grounding oftentimes leads to frustration on both sides. While the accessibility of these tools is lowering the bar to contributions, effective contributions still require foundational understanding of the project architecture, constraints, and expectations.
Another aspect here is that this ticket is talking about Spring Data Commons changes while the PR goes towards JPA. Let me know whether this helps.