[hibernate-dev] SQM - alias registry

Sanne Grinovero sanne at hibernate.org
Wed Oct 7 10:41:55 EDT 2015


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


More information about the hibernate-dev mailing list