To be clear, this is the feature that lets you define a query like:
select ... from Person p where p.name in (:names)
And then bind varied multiple values into that single parameter holder:
query.setParameterList( "names", new String[] { "Larry", "Curly", "Moe" } );
query.setParameterList( "names", new String[] { "John", "Jane" } );
Which magically transforms to the following (rough) SQL:
select ... from PERSON p where p.name in (?, ?, ?)
select ... from PERSON p where p.name in (?, ?)
Effectively parameter lists allow expansion of the HQL statement - they
literally are handled by altering the HQL on the fly as we prepare to
execute the query. What that means is that we can really not cache these
queries, at least not until the parameters are bound (which kind of defeats
the purpose).
I'd like to discuss dropping support for parameter lists. There are quite
a few reasons I would like to drop this support:
1. This is the main culprit that leads to the ever-resurrecting
discussion about DB limits on IN clauses. The one valid use case I saw for
that lead me to add multi-load support in 5.1.
2. In terms of a QueryPlan cache, this support means we can never
effectively cache the plans for these queries because the SQL is different
every time we execute the query. The problem though is that we do not know
this until well after the point that we'd resolve the QueryPlan.
chicken-egg.
3. This is more an internal detail, but handling the parameter bindings
for these differently gets quite complicated.
4. An additional internal detail is that re-writing the HQL on the fly
is problematic. And some of that leaks to the user in terms of result
caching and stats (which HQL do we use?).
I get that this can be a useful feature for apps that dynamically build
HQL, although really for dynamic query building I think a criteria approach
is more appropriate. It is not so much supporting this feature that bugs
me, it's how we expose it. So an alternative to dropping this support
would be to support it in a different way. The main issue is that I would
like to *syntactically* understanding that a parameter placeholder will be
used for multi-valued parameter from the query itself. This is a
beyond-JPA feature, so we definitely have some leeway here to define this
however we want.
I am open to suggestions as to the best syntax to declare that.
An alternative would be to make some assumptions. Specifically, the only
time I can think this is used is inside an IN predicate. Am I missing
others? If that is the case, we could simply assume that a IN predicate
with a single parameter placeholder is going to be a multivalued
parameter. That assumption holds valid even if just a single value is
bound. The main win there is that we can get rid of the Query#setParameterList
variants. setParameterList was only ever needed so that we could
understand that the parameter is multivalued - here we'd assume that from
its context as the IN predicate value.
Continuing to support parameters-lists in any form does not really
address point
(1) above; but that's ok - the user really could , But each of the
alternatives does help with the other problems currently stemming from
parameter-list support.
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
