On Sat, Sep 10, 2016 at 9:08 AM Christian Beikov <christian.bei...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
