We're updating the issue view to help you get more done. 

Created a unified "alias registry"

Description

Created a unified "alias registry" to make sure we do not have alias collisions between different clauses/contexts. For example, `select a.address as a from Anything as a`.

The spec is not completely explicit. However quotes from a few sections give us some principles that must be followed...

(JPA 2.1, section 4.4.2 Identification Variables)

All identification variables used in the SELECT, WHERE, ORDER BY, GROUP BY, or HAVING clause of a SELECT or DELETE statement must be declared in the FROM clause. The identification variables used in the WHERE clause of an UPDATE statement must be declared in the UPDATE clause.
...
An identification variable is scoped to the query (or subquery) in which it is defined and is also visible any subqueries within that query scope that do not define an identification variable of the same name.

2 main take-aways from here..

  1. It implies that aliases defined in the FROM clause are different (more on this below)

  2. The last sentence explicitly defines the rules around aliases in terms of parent/sub queries. An alias may in fact be redefined in a subquery in which case it "hides" the same alias from the parent query.

The other piece here is the implicit distinction between aliases defined in the FROM clause and aliases defined in the SELECT clause. The initial design of the alias registry disallowed reuse of an alias between SELECT and FROM clauses. I have not (yet?) seen anywhere that the spec says anything about this. In other words, nowhere have I seen that the spec disallows e.g. select a as a from A as a... where we have 'a' declared as both a SELECT alias (result_variable) and a FROM alias (identification_variable).

Comments below reference the discussion in the spec around ORDER BY which says, in part...

(JPA 2.1, section 4.9 ORDER BY Clause)

...
3. A general_identification_variable that evaluates to the same map field of the same entity or
embeddable abstract schema type as a general_identification_variable in the SELECT
clause
4. A result_variable that refers to an orderable item in the SELECT clause for which the same
result_variable has been specified. This may be the result of an aggregate_expression, a
scalar_expression, or a state_field_path_expression in the SELECT clause.

So here the spec says that that an "order by item" may be a SELECT alias (result_variable) or a FROM alias (identification_variable). But still it does not say anything about whether alias should or should not be allowed to be reused between SELECT and FROM. Kind of up to us. I think we all agree that a query like select a.b as a from A as a ... is completely confusing, but the question is whether we want to enforce that on to customers versus maybe just warning.

Environment

None

Status

Assignee

Andrea Boriero

Reporter

Steve Ebersole

Fix versions

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Priority

Major