[hibernate-dev] Continue "parameter list" support?

[Steve Ebersole]

On Sat, Sep 10, 2016 at 9:08 AM Christian Beikov <christian.beikov at gmail.com>
wrote:

> Will there be a way in SQM to specify the argument types of a function?
>

We have that today.  Not so much the "varargs" aspect, but if the user
registered that function as a SQLFunction then we would understand the
type(s) of arguments it accepts.



> If so, then you could introduce the concept of var-args and then a
> parameter will only be a multi-valued parameter if the function argument
> it is used for is a var-arg parameter.
>

Right, that would mean adjusting SQLFunction to report whether the
arguments are "varargs".  I plan on looking to change the SQLFunction
contract quite a bit already actually.  Today we render these (into the
SQL) via the method `String render(Type argumentType, List args,
SessionFactoryImplementor factory)` where the `args` is List<String>.  I'd
prefer that to be more OO than String.  In terms of SQM and SQL-tree, I'd
like that to be something like List<SqlTreeExpression>.  Heck I'd love for
these SQLFunctions themselves to implement SqlTreeExpression themselves and
embed them directly into the SQL-tree



> If not, then you probably need a custom syntax. Maybe something like
> ":param...", ":...param", ":*param" or ":param*"?
>

Yep, like I mentioned back in the original email.  This is an alternative
mean to making the question of "collection valued input parameter" versus
"single valued input parameter" deterministic from the grammar.  I
personally am not a fan of this, but just mentioned it for completeness.

HHH-10502 is an example of a "corner case".  The placeholder is reused, and
one is already deterministic to accept "collection valued input
parameter".  So we could understand that across both usages.  We have to be
clear that this this non-compliant JPA usage, however.

Either way, if we are going to allow a "collection valued input parameter"
in contexts not allowed strictly under JPA then this needs to be hooked in
with org.hibernate.sqm.ConsumerContext#useStrictJpaCompliance
and org.hibernate.sqm.StrictJpaComplianceViolation