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

The direction I went for now was to push collection of the parameters to SQM itself and expose that from SqmStatement#getQueryParameters. Additionally I have SQM validate the positional parameters per JPA spec (1-based, contiguous). I added

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The parameter expansion would happen on the SQM as we translate it to the "SQL tree" (mutli-step translation). What we need to know up front (ideally) is: 1. "parameter metadata" 2. "result metadata" We can glean all that from SQM. Today that lives on the QueryPlan (HQLQueryPlan). The

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

Hmm I think I understand what you mean now. How would you do parameter expansion in SQM? Or will the result after a parameter expansion not be cached? Am 09.09.2016 um 23:35 schrieb Steve Ebersole: > Not any particular reason, HHH-10502 or otherwise. Its more a general > question as I am

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

Although, thinking about it some more, SQM itself already exposes some of the things QueryPlan does today. So maybe this is not such a big issue. I personally am just not a fan of not understanding the semantic of a query up front. Good translation in part comes down to good design of the

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

Not any particular reason, HHH-10502 or otherwise. Its more a general question as I am integrating SQM and the new query translators upstream. Again, I think y'all are missing the point. The concern is not whether a query is cacheable or not. The concern is *when* I know whether it is

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

Ah ok, I thought you wanted to drop parameter lists in general ^^ I suppose you are discussing this because of https://hibernate.atlassian.net/browse/HHH-10502? I personally don't have a use case for a general parameter list expansion like the reporter of that issue and I also don't think that

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

BTW, JPA really requires that we support accepting multi-valued bindings for parameters through #setParameter. Yet another reason to do away with #setParameterList. On Fri, Sep 9, 2016 at 3:26 PM Steve Ebersole wrote: > WRT the "collection_valued_input_parameter" bit,

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

WRT the "collection_valued_input_parameter" bit, that is limited in the spec to IN clauses. And more specifically in fact the spec specifically limits this in *exactly* the way I suggested :) in_expression ::= {state_valued_path_expression | type_discriminator} [ NOT ] IN {

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

Hi, I don't think we should deprecate such a feature. First, the JPA specs says the follows: "All input parameters must be single-valued, except in IN expressions (see section 4.6.9), which support the use of collection-valued input parameters." So, we kinda need to support it one way or

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

I am also not able to figure out another use case than the IN predicate so I am for always considering IN predicates as multi-valued. On 9 September 2016 at 14:20, Steve Ebersole wrote: > To be clear, this is the feature that lets you define a query like: > > select ...

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

Well the BNF in the JPA 2.1 spec contains "collection_valued_input_parameter" which resembles this parameter list, so dropping support for that would make Hibernate non JPA compliant I guess. If you are concerned with caching, I think the parameter lists could be expanded to a

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

To be clear, this is the feature that lets you define a query like: select ... from Person p where p.name in (:names) And then bind varied multiple values into that single parameter holder: query.setParameterList( "names", new String[] { "Larry", "Curly", "Moe" } ); query.setParameterList(