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
