So @beikov, to my way of thinking, this restriction is actually reasonably well-motivated.

As you well know, some databases are extremely finicky about where they allow parameters in a SQL statement. And I bet that even now there are some platforms that disallow them in order by. (But you probably know better than me.)
We don't want to allow parameters in the select clause in a completely unrestricted way, because then queries like select title, ?1 from Book can't be typed without having an argument to ?1. So we would have to figure out what the restrictions are.
I suppose parameters in on restrictions are OK, though the truth is I simply don't know. I don't think they're at all common.
I suppose parameters in group by are mostly OK, though they don't seem terribly useful to me. I doubt they're common.

The thing is that actually existing JPA implementations don't (I guess) impose enforce this restriction. Rather, they let you use parameters wherever you like, and then blow up if the database doesn't like it. For the spec to impose a blanket requirement that parameters are allowed anywhere, and for the TCK to test that, might require providers having to implement really nasty and impractical workarounds. (Remember, we certify on Derby, which is hot garbage in this area.)

The spec is saying what providers have to support. It's not limiting what they can support.

So honestly I think this is basically fine. However, I would suggest a slight change in wording, from:

Input parameters can only be used in the WHERE clause or HAVING clause of a query or as the new value for an update item in the SET clause of an update statement.

To:

A provider is only required to support Input parameters in the WHERE clause or HAVING clause of a query or as the new value for an update item in the SET clause of an update statement.

WDYT?

Lift input parameter restrictions #103

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions