> Here the aliases `c` do infringe. In the subquery, we don't really know > which reference the `c` alias should resolve to. We *could* here assuming > that the subquery is uncorrelated. Bu without this rule we really would > not know that the subquery is correlated Out of curiosity, Couldn't for this case assume that the second alias overrides the first. This might cause some hard to spot errors, though.

On 7 October 2015 at 15:27, Steve Ebersole <steve(a)hibernate.org&gt; wrote: >> >> > Here the aliases `c` do infringe. In the subquery, we don't really know >> > which reference the `c` alias should resolve to. We *could* here >> assuming >> > that the subquery is uncorrelated. Bu without this rule we really would >> > not know that the subquery is correlated >> >> Out of curiosity, Couldn't for this case assume that the second alias >> overrides the first. >> This might cause some hard to spot errors, though. >> > > The issue really is for cases of correlated subqueries (where the subquery > refers to the outer query). So imagine a query such as: > > select ... > from Salesperson s > where exists ( > select count(*) > from Sale s2 > where s.id = s2.salesperson.id ... > group by s2.salesperson.id > having count(*) > :sales > ) > > So here the predicate `s.id = s2.salesperson.id` defines a correlation > beween hthe queries. If we allowed the "alias overriding", it is quite > possible for the user to (mistakenly) write this query as: > > select ... > from Salesperson s > where exists ( > select count(*) > from Sale s > where s.id = s.salesperson.id ... > group by s.salesperson.id > having count(*) > :sales > ) > > Which validates fine, but is not *really* what they meant and would not > return what they are looking for. So the question is about allowing or disallowing variable shadowing. Java allows it, and since Hibernate targets Java developers mostly, being consistent with that has some merits - after all I think people know that using shadowing is a bad idea so I wouldn't stress too much about it. Still if it's not too complex to ban it, that might be nicer: this is not a general purpose language like Java so the improvement could be welcome. I certainly see no problems with preventing mistakes.

On 7 October 2015 at 15:41, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > On 7 October 2015 at 15:39, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: >> On 7 October 2015 at 15:27, Steve Ebersole <steve(a)hibernate.org&gt; wrote: >>>>> Here the aliases `c` do infringe. In the subquery, we don't really know >>>>> which reference the `c` alias should resolve to. We *could* here >>>> assuming >>>>> that the subquery is uncorrelated. Bu without this rule we really would >>>>> not know that the subquery is correlated >>>> Out of curiosity, Couldn't for this case assume that the second alias >>>> overrides the first. >>>> This might cause some hard to spot errors, though. >>>> >>> The issue really is for cases of correlated subqueries (where the subquery >>> refers to the outer query). So imagine a query such as: >>> >>> select ... >>> from Salesperson s >>> where exists ( >>> select count(*) >>> from Sale s2 >>> where s.id = s2.salesperson.id ... >>> group by s2.salesperson.id >>> having count(*) > :sales >>> ) >>> >>> So here the predicate `s.id = s2.salesperson.id` defines a correlation >>> beween hthe queries. If we allowed the "alias overriding", it is quite >>> possible for the user to (mistakenly) write this query as: >>> >>> select ... >>> from Salesperson s >>> where exists ( >>> select count(*) >>> from Sale s >>> where s.id = s.salesperson.id ... >>> group by s.salesperson.id >>> having count(*) > :sales >>> ) >>> >>> Which validates fine, but is not *really* what they meant and would not >>> return what they are looking for. >> So the question is about allowing or disallowing variable shadowing. >> >> Java allows it, and since Hibernate targets Java developers mostly, >> being consistent with that has some merits - after all I think people >> know that using shadowing is a bad idea so I wouldn't stress too much >> about it. >> >> Still if it's not too complex to ban it, that might be nicer: this is >> not a general purpose language like Java so the improvement could be >> welcome. I certainly see no problems with preventing mistakes. So I just wrote I see no problems with doing so, then I realized there might be one: far fetched, but better mention it: What about tools which generate HQL? I'm thinking about third party projects which use Hibernate, maybe like Teiid. It might be more complex for anyone generating HQL programmatically to deal with such strict scoping rules. It might be far-fetched, I don't really know how common that could be, nor how easily such integrators could fix it. Are you sure you'd not be adding a restriction which is more relaxed in the JPA spec? That would make it potentially harder to migrate older Hibernate applications, or when migrating from other JPA implementors.. I'd hope for example that some known benchmarks, which we have to run unmodified, don't use such syntax ;)

_______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Ah, good call. I found this in the spec: <quote> An identification variable is scoped to the query (or subquery) in which it is defined and is also visible to any subqueries within that query scope that do not define an identification variable of the same name. </quote> They define "identification variable" specifically as aliases declared in the FROM-clause. Based on this same line of questioning, I am not so sure that the spec disallows at all what we do with the alias registry in terms of disallowing the same alias in from-clause and select-clause. Essentially I think we need to completely redesign this alias checking. On Wed, Oct 7, 2015 at 10:13 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > On 7 October 2015 at 15:41, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > > On 7 October 2015 at 15:39, Sanne Grinovero <sanne(a)hibernate.org&gt; > wrote: > >> On 7 October 2015 at 15:27, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >>>> > >>>> > Here the aliases `c` do infringe. In the subquery, we don't > really know > >>>> > which reference the `c` alias should resolve to. We *could* here > >>>> assuming > >>>> > that the subquery is uncorrelated. Bu without this rule we really > would > >>>> > not know that the subquery is correlated > >>>> > >>>> Out of curiosity, Couldn't for this case assume that the second alias > >>>> overrides the first. > >>>> This might cause some hard to spot errors, though. > >>>> > >>> > >>> The issue really is for cases of correlated subqueries (where the > subquery > >>> refers to the outer query). So imagine a query such as: > >>> > >>> select ... > >>> from Salesperson s > >>> where exists ( > >>> select count(*) > >>> from Sale s2 > >>> where s.id = s2.salesperson.id ... > >>> group by s2.salesperson.id > >>> having count(*) > :sales > >>> ) > >>> > >>> So here the predicate `s.id = s2.salesperson.id` defines a > correlation > >>> beween hthe queries. If we allowed the "alias overriding", it is > quite > >>> possible for the user to (mistakenly) write this query as: > >>> > >>> select ... > >>> from Salesperson s > >>> where exists ( > >>> select count(*) > >>> from Sale s > >>> where s.id = s.salesperson.id ... > >>> group by s.salesperson.id > >>> having count(*) > :sales > >>> ) > >>> > >>> Which validates fine, but is not *really* what they meant and would > not > >>> return what they are looking for. > >> > >> So the question is about allowing or disallowing variable shadowing. > >> > >> Java allows it, and since Hibernate targets Java developers mostly, > >> being consistent with that has some merits - after all I think people > >> know that using shadowing is a bad idea so I wouldn't stress too much > >> about it. > >> > >> Still if it's not too complex to ban it, that might be nicer: this is > >> not a general purpose language like Java so the improvement could be > >> welcome. I certainly see no problems with preventing mistakes. > > So I just wrote I see no problems with doing so, then I realized there > might be one: far fetched, but better mention it: > > What about tools which generate HQL? I'm thinking about third party > projects which use Hibernate, maybe like Teiid. > It might be more complex for anyone generating HQL programmatically to > deal with such strict scoping rules. > > It might be far-fetched, I don't really know how common that could be, > nor how easily such integrators could fix it. > > Are you sure you'd not be adding a restriction which is more relaxed > in the JPA spec? > That would make it potentially harder to migrate older Hibernate > applications, or when migrating from other JPA implementors.. I'd hope > for example that some known benchmarks, which we have to run > unmodified, don't use such syntax ;) >

> > > Here the aliases `c` do infringe. In the subquery, we don't really know > > which reference the `c` alias should resolve to. We *could* here > assuming > > that the subquery is uncorrelated. Bu without this rule we really would > > not know that the subquery is correlated > > Out of curiosity, Couldn't for this case assume that the second alias > overrides the first. > This might cause some hard to spot errors, though. > The issue really is for cases of correlated subqueries (where the subquery refers to the outer query). So imagine a query such as: select ... from Salesperson s where exists ( select count(*) from Sale s2 where s.id = s2.salesperson.id ... group by s2.salesperson.id having count(*) > :sales ) So here the predicate `s.id = s2.salesperson.id` defines a correlation beween hthe queries. If we allowed the "alias overriding", it is quite possible for the user to (mistakenly) write this query as: select ... from Salesperson s where exists ( select count(*) from Sale s where s.id = s.salesperson.id ... group by s.salesperson.id having count(*) > :sales ) Which validates fine, but is not *really* what they meant and would not return what they are looking for. _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev