[hibernate-dev] SQM - alias registry

[John O'Hara]

On 07/10/15 15:48, Sanne Grinovero wrote:
> On 7 October 2015 at 15:41, Sanne Grinovero <sanne at hibernate.org> wrote:
>> 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.
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
John O'Hara
johara at 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).