BTW... the question is not necessarily whether that parameter *is*
multi-valued. The question is whether it *can be* multi-valued.
So from the initial SQM build we'd understand that a particular parameter
is used in a way that indicated that its binding might be multi-valued.
When we resolve that to a SQLFunction, e.g., we'd be able to ask the
SQLFunction if it accepts varargs and:
if ( sqmFunctionArgumentParameter.allowsMultiValues() ) {
if ( !sqlFunction.acceptsVarargs() ) {
log.debug( "SQLFunction [%s] does not accept varargs, adjusting
SqmParameterExpression [%s] used as argument to not allow multi-values, ..
);
sqmFunctionArgumentParameter.allowMultiValues( false );
}
}
On Sat, Sep 10, 2016 at 9:53 AM Steve Ebersole <st...@hibernate.org> wrote:
> We are actually getting close to being able to wholly determine FUNCTION
> syntactically. So adding support for "collection valued input
> parameters" as function arg should be pretty straight forward.
>
> And validation-wise I think it still works out nicely. Basically that
> leaves us 3 conditions:
>
> 1. "collection valued input parameters" as IN expression value -
> supported by HQL and JPQL
> 2. "collection valued input parameters" as (final) function argument -
> supported by HQL but not JPQL strictly
> 3. "collection valued input parameters" anywhere else - not supported
> in HQL or JPQL
>
>
>
>
> On Sat, Sep 10, 2016 at 9:43 AM Christian Beikov <
> christian.bei...@gmail.com> wrote:
>
>> My idea was to allow a parameter to be a collection valued parameter
>> only in two cases
>>
>> 1. When used with the IN predicate
>> 2. When used as last argument for a function and the parameter is a
>> var-arg parameter
>>
>> That way the query can be validated upfront when knowing the registered
>> functions and their argument types, but it's obviously not clear from
>> just looking at the query string if a parameter is multi-valued or not.
>> If you want to make the semantics independent of the functions, then you
>> must introduce a syntax of course. I was just trying to suggest
>> something that is mostly compatible to the way it is right now.
>>
>> Am 10.09.2016 um 16:10 schrieb Steve Ebersole:
>> > WRT the "double caches"... yes there will be a few caches.
>> >
>> > I'm not understanding what that has to do with defining a clear
>> > semantic for a particular language element.
>> >
>> > ----
>> >
>> > Look, to me this whole thing boils down to the fact that JPA defines
>> > specific/limited support for this "collection valued input parameter"
>> > language element. It does that btw because the ideal in language
>> > design is to be able to wholly understand the semantic of a part of a
>> > query based only on the syntax[1]. Further, JPA requires that we
>> > handle a user binding a "collection valued input parameter" directly
>> > through #setParameter.
>> >
>> > So all told we have a set of overloaded methods (#setParameterList)
>> > that are not really providing any value[2], but that are needed
>> > because that provides the only indication we ever get that a
>> > particular parameter placeholder identifies a "collection valued input
>> > parameter" rather than a"single valued input parameter". For all the
>> > reasons discussed[1], thats not the ideal language design because it
>> > is not deterministic from the grammar.
>> >
>> > Think of it this way... It would be nice++ to be able to say "this
>> > parameter is allowing multi-valued input" or "this parameter is
>> > expecting single-valued input (multi-value input disallowed)", right?
>> > Its the whole reason JPA defines its grammar (BNF) the way it does, so
>> > that we can properly validate the incoming parameter input. Today I
>> > can do something like this:
>> >
>> > s.createQuery("from Zoo z where z.name <http://z.name> = :name" )
>> > .setParameterList("name",new String[] {"San Antonio Zoo","Waco
>> Zoo" } )
>> > .list();
>> > That is a completely "valid" query. Its not going to return anything
>> > useful, but syntactically it is valid because we cannot understand the
>> > proper semantic. And we do not understand the proper semantic
>> > because it is not deterministic wrt the grammar/syntax. Ideally you'd
>> > want to throw an exception back to the user here as soon as they try
>> > to call #setParameterList for a parameter we conceptually *know*
>> > should not accept "collection valued input parameters"
>> >
>> > ----
>> >
>> > [1] This gets into language and grammar design, but there are a few
>> > reasons you want to encode as much semantic understanding into the
>> > syntax as possible. There are a few reasons for this; the 2 main ones
>> > for us:
>> >
>> > 1. validation - again, here if I understand that a parameter
>> > placeholder should or should-not allow "collection valued input
>> > parameter" I can apply better validation up front (the sooner this
>> > type of feedback can happen the better)
>> > 2. performance - anytime the query itself is not clear as to its
>> > semantic there is going to be a performance aspect to resolving
>> > that unclarity.
>> >
>> > [2] I can see the argument of #setParameterList providing a better API
>> > for passing the multi-value bind value in terms of type signature.
>> > But ultimately IMO both "collection valued input parameter" and
>> > "single valued input parameter" ought to be stored in one structure.
>> > Today they are not, can't because we need to know that
>> > #setParameterList was called instead of #setParameter because that is
>> > our only understanding of the semantic - that this is a "collection
>> > valued input parameter", not a"single valued input parameter".
>> >
>> >
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
