4 p.m.
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
from Order o
...
)
or c.id in (
select c1.id
from Outstanding o
...
)
Here the aliases `o` don't ever infringe on each other. So imo we should
allow that.
The piece about checking the parent is for a case like:
select ...
from Customer c
where c.id in (
select c.id
from Order o
join o.customer c
...
)
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. Hopefully that makes sense, what
I am getting at.
WDYT?
4:15 p.m.
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 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.
On Wed, Oct 7, 2015 at 3:00 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
> 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
> from Order o
> ...
> )
> or c.id in (
> select c1.id
> from Outstanding o
> ...
> )
>
Here the aliases `o` don't ever infringe on each other. So imo
we should
> allow that.
>
> The piece about checking the parent is for a case like:
> select ...
> from Customer c
> where c.id in (
> select c.id
> from Order o
> join o.customer c
> ...
> )
>
> 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. Hopefully that makes sense, what
> I am getting at.
>
> WDYT?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
4:19 p.m.
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 <steve(a)hibernate.org> wrote:
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
from Order o
...
)
or c.id in (
select c1.id
from Outstanding o
...
)
Here the aliases `o` don't ever infringe on each other. So imo we should
allow that.
The piece about checking the parent is for a case like:
select ...
from Customer c
where c.id in (
select c.id
from Order o
join o.customer c
...
)
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. Hopefully that makes sense, what
I am getting at.
WDYT?
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:27 p.m.
> 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.
4:39 p.m.
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.
4:41 p.m.
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.
4:48 p.m.
On 7 October 2015 at 15:41, 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.
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 ;)
4:53 p.m.
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.
5:10 p.m.
On 07/10/15 15:48, Sanne Grinovero wrote:
On 7 October 2015 at 15:41, 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.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
John O'Hara
johara(a)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).
5:28 p.m.
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 <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.
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:31 p.m.
Ah, good call. I found this in the spec:
<quote>
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.
</quote>
They define "identification variable" specifically as aliases declared in
the FROM-clause.
Based on this same line of questioning, I am not so sure that the spec
disallows at all what we do with the alias registry in terms of disallowing
the same alias in from-clause and select-clause. Essentially I think we
need to completely redesign this alias checking.
On Wed, Oct 7, 2015 at 10:13 AM Sanne Grinovero <sanne(a)hibernate.org> wrote:
On 7 October 2015 at 15:41, 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.
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 ;)
5:37 p.m.
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 the hierarchy (parent/child) of the query specs and that
distinguishes between FROM and SELECT aliases (what the spec calls
"identification_variable" and "result_variable", respectively. Within
a
scope (a specific alias instance) it would be illegal for the same
identification_variable
to be defined twice or for the same result_variable to be defined twice.
However, if the same identification_variable or result_variable exists just
i the parent scope, that is ok.
On Wed, Oct 7, 2015 at 10:31 AM Steve Ebersole <steve(a)hibernate.org> wrote:
Ah, good call. I found this in the spec:
<quote>
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.
</quote>
They define "identification variable" specifically as aliases declared in
the FROM-clause.
Based on this same line of questioning, I am not so sure that the spec
disallows at all what we do with the alias registry in terms of disallowing
the same alias in from-clause and select-clause. Essentially I think we
need to completely redesign this alias checking.
On Wed, Oct 7, 2015 at 10:13 AM Sanne Grinovero <sanne(a)hibernate.org>
wrote:
> On 7 October 2015 at 15:41, 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.
>
> 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 ;)
>
3124
days inactive
3124
days old
11 comments
5 participants
participants (5)
-
andrea boriero -
Davide D'Alto -
John O'Hara -
Sanne Grinovero -
Steve Ebersole