On 07/10/15 15:48, Sanne Grinovero wrote: > On 7 October 2015 at 15:41, 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. > 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 ;) The benchmarks we run don't contain any correlated subqueries. > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev
-- John O'Hara joh...@redhat.com JBoss, by Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland). _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
