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 <sanne(a)hibernate.org> wrote:
On 7 October 2015 at 15:39, Sanne Grinovero
<sanne(a)hibernate.org> wrote:
> On 7 October 2015 at 15:27, Steve Ebersole <steve(a)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.