如何防止 OpenJPA 替换查询中的 "constant" 参数?
How can I prevent OpenJPA from replacing "constant" parameters in my queries?
我似乎对 CHAR
字段的查询有问题,当 OpenJPA 用 SQL 参数替换我的常量值时,该字段被错误过滤。
例子
鉴于此 table 在 Oracle
create table PERSON (
id char(10) not null,
type char(3) not null,
primary key (id)
)
type
具有三个不同的值:WTW、WAI、V
和相应的实体
@Entity
public class Person {
String id;
String type;
}
我使用 orm.xml 文件中的以下查询:
<named-query name="person.v">
<query>
select p
from Person p
where p.type = 'V'
</query>
</named-query>
问题
当我通过 OpenJPA 提供的 EntityManager 运行 时,查询变为
select p.id, p.type
from PERSON p
where p.type = ?
并且 OpenJPA 将值 "V"
作为参数传递。 type
的先前 "constant" 值现在是 SQL 参数。问题在于,对于 char(3)
type
列,Oracle 将存储
"V "
这不等于 OpenJPA 作为参数传递的值。同样:没有参数,即仅使用我在 JPQL 中使用的 SQL 中的字符串,一切正常。
我假设 OpenJPA 执行此替换是为了通过规范化所有查询来最小化查询缓存,我知道这对很多人来说有很大的不同,但我认为这对我来说是个问题。
我现在的问题是:如何防止 OpenJPA 进行此替换?我知道在 运行 时我不会有此查询的不同排列。是否有我可以使用的配置 属性 或查询提示?
除了将列更改为 VARCHAR
之外,我还有两个不太好的解决方法:
- 将 JPQL 调整为
where p.type = 'V '
("V" 后跟两个空格)。
- 使用 OpenJPA 不会优化的本机查询。
在 (1) 中,我知道底层 char(3)
并且 JPQL 的想法是将其抽象掉,所以这与使用 JPA 的想法有点背道而驰。
对于 (2),我不得不稍微重写这个简单的查询,但使用本机查询只是为了避免持久性提供程序的良好意图造成的问题似乎并不正确。
我似乎对 CHAR
字段的查询有问题,当 OpenJPA 用 SQL 参数替换我的常量值时,该字段被错误过滤。
例子
鉴于此 table 在 Oracle
create table PERSON (
id char(10) not null,
type char(3) not null,
primary key (id)
)
type
具有三个不同的值:WTW、WAI、V
和相应的实体
@Entity
public class Person {
String id;
String type;
}
我使用 orm.xml 文件中的以下查询:
<named-query name="person.v">
<query>
select p
from Person p
where p.type = 'V'
</query>
</named-query>
问题
当我通过 OpenJPA 提供的 EntityManager 运行 时,查询变为
select p.id, p.type
from PERSON p
where p.type = ?
并且 OpenJPA 将值 "V"
作为参数传递。 type
的先前 "constant" 值现在是 SQL 参数。问题在于,对于 char(3)
type
列,Oracle 将存储
"V "
这不等于 OpenJPA 作为参数传递的值。同样:没有参数,即仅使用我在 JPQL 中使用的 SQL 中的字符串,一切正常。
我假设 OpenJPA 执行此替换是为了通过规范化所有查询来最小化查询缓存,我知道这对很多人来说有很大的不同,但我认为这对我来说是个问题。
我现在的问题是:如何防止 OpenJPA 进行此替换?我知道在 运行 时我不会有此查询的不同排列。是否有我可以使用的配置 属性 或查询提示?
除了将列更改为 VARCHAR
之外,我还有两个不太好的解决方法:
- 将 JPQL 调整为
where p.type = 'V '
("V" 后跟两个空格)。 - 使用 OpenJPA 不会优化的本机查询。
在 (1) 中,我知道底层 char(3)
并且 JPQL 的想法是将其抽象掉,所以这与使用 JPA 的想法有点背道而驰。
对于 (2),我不得不稍微重写这个简单的查询,但使用本机查询只是为了避免持久性提供程序的良好意图造成的问题似乎并不正确。