Yes, but generally speaking Java gives you alternative ways to reference to hidden/shadowed names, sql/hql/jpql do not.
On Wed, Oct 7, 2015 at 9:42 AM Sanne Grinovero <sa...@hibernate.org> wrote: > On 7 October 2015 at 15:39, Sanne Grinovero <sa...@hibernate.org> wrote: > > On 7 October 2015 at 15:27, Steve Ebersole <st...@hibernate.org> 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. > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
