-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite queries using LIKE with wildcards using CONCAT. #2939
Comments
We support wrapping parameters (named or positional) with optional wildcards when doing LIKE patterns. This is out-of-band and requires moving the wildcards into the bindings. To stop doing this and causing race conditions, we can instead rewrite the queries using the CONCAT function. This function is standard across relational database (native queries) as well as JPA providers (Hibernate and EclipseLink). Resolves #2939. Related: #2760.
We support wrapping parameters (named or positional) with optional wildcards when doing LIKE patterns. This is out-of-band and requires moving the wildcards into the bindings. To stop doing this and causing race conditions, we can instead rewrite the queries using the CONCAT function. This function is standard across relational database (native queries) as well as JPA providers (Hibernate and EclipseLink). Resolves #2939. Related: #2760. Original Pull Request: #2944.
We support wrapping parameters (named or positional) with optional wildcards when doing LIKE patterns. This is out-of-band and requires moving the wildcards into the bindings. To stop doing this and causing race conditions, we can instead rewrite the queries using the CONCAT function. This function is standard across relational database (native queries) as well as JPA providers (Hibernate and EclipseLink). Resolves #2939. Related: #2760. Original Pull Request: #2940. Superceding Pull Request: #2944
We support wrapping parameters (named or positional) with optional wildcards when doing LIKE patterns. This is out-of-band and requires moving the wildcards into the bindings. To stop doing this and causing race conditions, we can instead rewrite the queries using the CONCAT function. This function is standard across relational database (native queries) as well as JPA providers (Hibernate and EclipseLink). See #2939 See #2760 Original Pull Request: #2940 Superceding Pull Request: #2944
We support wrapping parameters (named or positional) with optional wildcards when doing LIKE patterns. This is out-of-band and requires moving the wildcards into the bindings. To stop doing this and causing race conditions, we can instead rewrite the queries using the CONCAT function. This function is standard across relational database (native queries) as well as JPA providers (Hibernate and EclipseLink). See #2939 See #2760 Original Pull Request: #2940 Superceding Pull Request: #2944
We support wrapping parameters (named or positional) with optional wildcards when doing LIKE patterns. This is out-of-band and requires moving the wildcards into the bindings. To stop doing this and causing race conditions, we can instead rewrite the queries using the CONCAT function. This function is standard across relational database (native queries) as well as JPA providers (Hibernate and EclipseLink). See #2939 See #2760 Original Pull Request: #2940 Superceding Pull Request: #2944
Hi, this unfortunately breaks pgjdbc-ng. A jdbc driver that is not very well maintained at the moment, and in the process of beeing transferred to the postgresql organization (impossibl/pgjdbc-ng#588). |
This is a breaking change for Oracle databases because CONCAT supports only two arguments. The query now contains |
I know this is a hassle, but you could try to rewrite the jpa query by using concat directly. It then skips the jpa code that replaces the like ... with concat ... , ahtough you would probably have to nest 2 concats to get around the oracle oddity of conact only supporting two parameters. https://docs.oracle.com/cd/B13789_01/server.101/b10759/functions022.htm. |
Queries like
select e from EmployeeWithName e where e.name like %:partialName%
is shorthand forselect e from EmployeeWithName e where e.name like :partialName
where the bound input value gets wrapped with percentage wildcards. It works when it's the only usage of that parameter in the query.However if that parameter is used more than once in the query, there is a race condition that can cause the query to get changed into something different.
By replacing this with
CONCAT('%', :param, '%')
, we are able to use a very widely used standard function across both native and JPA providers to achieve the same effect. This lets us STOP adding wildcards to parameter bindings, and eliminates the race condition seen in places like #2760.The text was updated successfully, but these errors were encountered: