G
Giovanni Azua
hello,
Suppose I'm given a valid JPQL query and I would like to find out how many
rows it would return if executed but without actually executing it.
Example input JPQL: select p from Person p where p.name like "Giov%"
and I would like to generate something like (this one does not work):
select count(e) from (<the input query here>) e
select count(e) from (select p from Person p where p.name = "Giovanni") e
I have tried several JPQL possibilities without success. The context of this
problem is while implementing the Value List Handler Pattern, the lazy
strategy would not execute the actual query immediately but needs to know
what the total number of records is so the iterator state can be consistent.
The other possibility I was considering was to accept not only the query as
input but also the corresponding count reporting query too. However, this is
somewhat redundant and error-prone because the client could in theory hand
in a wrong reporting query that would not match the original query.
I think this kind of query is ANSI SQL therefore supported by all Database
vendors, hence using native queries would be cool ... but it feels wrong
stepping aside from JPQL
TIA,
regards,
Giovanni
Suppose I'm given a valid JPQL query and I would like to find out how many
rows it would return if executed but without actually executing it.
Example input JPQL: select p from Person p where p.name like "Giov%"
and I would like to generate something like (this one does not work):
select count(e) from (<the input query here>) e
select count(e) from (select p from Person p where p.name = "Giovanni") e
I have tried several JPQL possibilities without success. The context of this
problem is while implementing the Value List Handler Pattern, the lazy
strategy would not execute the actual query immediately but needs to know
what the total number of records is so the iterator state can be consistent.
The other possibility I was considering was to accept not only the query as
input but also the corresponding count reporting query too. However, this is
somewhat redundant and error-prone because the client could in theory hand
in a wrong reporting query that would not match the original query.
I think this kind of query is ANSI SQL therefore supported by all Database
vendors, hence using native queries would be cool ... but it feels wrong
stepping aside from JPQL
TIA,
regards,
Giovanni