On 07/10/15 15:48, Sanne Grinovero wrote:
> On 7 October 2015 at 15:41, Sanne Grinovero wrote:
>> On 7 October 2015 at 15:39, Sanne Grinovero wrote:
>>> On 7 October 2015 at 15:27, Steve Ebersole wrote:
>> Here the aliases `c` do infringe. In the subquery, we don't really know
>> which
What makes the second query "badly written"? That is the fundamental issue
here. Its not badly written in terms of us being able to recognize that
how the spec says we should interpret it is not what the user intended.
So basically what I think we need is to design an alias registry that
follows
In my opinion if we want to allow aliases overriding the scope should
follows the Java rules, it's easier to understand for a Java developer and
the second query should just be considered a bad written one.
On 7 October 2015 at 15:27, Steve Ebersole wrote:
> >
> > > Here the aliases `c` do infr
Ah, good call. I found this in the spec:
An identification variable is scoped to the query (or subquery) in which it
is defined and is also visible
to any subqueries within that query scope that do not define an
identification variable of the same name.
They define "identification variable" sp
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 wrote:
> On 7 October 2015 at 15:39, Sanne Grinovero wrote:
> > On 7 October 2015 at 15:27, Steve Ebersole wrote:
> >>>
> >>>
On 7 October 2015 at 15:41, Sanne Grinovero wrote:
> On 7 October 2015 at 15:39, Sanne Grinovero wrote:
>> On 7 October 2015 at 15:27, Steve Ebersole wrote:
> Here the aliases `c` do infringe. In the subquery, we don't really know
> which reference the `c` alias should resolve to
On 7 October 2015 at 15:39, Sanne Grinovero wrote:
> On 7 October 2015 at 15:27, Steve Ebersole 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
On 7 October 2015 at 15:27, Steve Ebersole 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
>> > n
>
> > 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 curios
Hi Steve,
yes that seems very reasonable.
+1 for checking the parent "scope" too, I think that would feel
natural as it matches the scope rules of variables in Java.
On 7 October 2015 at 15:00, Steve Ebersole wrote:
> At the moment the alias registry is global for the whole query. I propose
> t
> Here the aliases `o` don't ever infringe on each other. So imo we should
allow that.
Sounds good
> 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 with
At the moment the alias registry is global for the whole query. I propose
that we should scope this by "query spec" (combined with parent). The
reason being that reusing the same alias in unrelated subqueries is
perfectly fine.
select ...
from Customer c
where c.id in (
select o.customer.id
12 matches
Mail list logo
