Created a unified "alias registry"


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
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.




Steve Ebersole
August 27, 2015, 1:18 PM

Well like any spec, it requires you understanding other parts as well in reading a specific part. So here it mentions "abstract schema type". That phrase is how the JPA spec defines the total of all the things contained in the from clause. So specifically it is talking about:

In a way you could make the argument that it is making an implicit requirement that this is actually to be handled as if the real query was:

and that the order-by has to refer to aliases in the select clause.

Gunnar Morling
August 27, 2015, 1:40 PM

Yes, that's my understanding, a definition of the alias in the select clause is needed. Specifically, as it later on some examples are shown which "are not legal because the orderby_item is not reflected in the SELECT clause of the query", suggesting that this is a general requirement. Anyways, my vote remains the same.

Steve Ebersole
October 15, 2015, 8:22 AM

This needs to be done differently. I am going to be rewording the description to cover exactly what needs to happen here.

Andrea Boriero
November 6, 2015, 12:09 PM

A new PR

As discussed with the PR follows 2 principles:
1. It's ok to reuse an identification variable as a result variable as long as they both refer to the same thing (the From Element)
2. An Identification variable can only be used in subqueries, it's completely invalid to reuse them in the same query spec.

Steve Ebersole
December 6, 2018, 3:43 PM

Preparing Alpha1 release


Andrea Boriero


Steve Ebersole

Fix versions





Suitable for new contributors


Requires Release Note


Pull Request