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
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:
Just to follow up on something I said below...
On Sat, Sep 10, 2016 at 9:27 AM Steve Ebersole wrote:
> 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 ren
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
On Sat, Sep 10, 2016 at 9:08 AM Christian Beikov
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 i
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 in
Will there be a way in SQM to specify the argument types of a function?
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.
If not, then you probably need a custom synta
Semantic means the "meaning" of something, but also the "intent". Here,
specifically, the intent is "is this param placeholder representing a
single- or multi-valued parameter? So I'll ask you... Given a query:
"from Something order by field( id, :param )"
Does ":param" represent a single- or m
May I ask how the semantics of a query could change in case of parameter
expansion in different places than IN predicate?
Since such collection valued parameters only make sense on some sort of
varg-args accepting thingy like IN or a SQLFunction, I don't really see
how this is an issue.
You cou
