Emmanuel... any idea where the best place in the current annotation binding
code to put such a check?
On Wed, Oct 7, 2015 at 9:26 AM andrea boriero wrote:
> +1
>
> On 7 October 2015 at 14:31, Steve Ebersole wrote:
>
>> I personally don't really see much of a justification for supporting
>> thi
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
+1
On 7 October 2015 at 14:31, Steve Ebersole wrote:
> I personally don't really see much of a justification for supporting
> this. If no one else can help me see the justification, I will just reject
> the feature request; however it probably is a good idea to give a better
> indication tat th
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
> however it probably is a good idea to give a better indication tat this
is not supported aside from some deeply nested NPE .
+1
On Wed, Oct 7, 2015 at 2:31 PM, Steve Ebersole wrote:
> I personally don't really see much of a justification for supporting
> this. If no one else can help me see
I personally don't really see much of a justification for supporting this.
If no one else can help me see the justification, I will just reject the
feature request; however it probably is a good idea to give a better
indication tat this is not supported aside from some deeply nested NPE .
On Wed,
I don't figure out the use cases for @Formula on @Id as well
On 7 October 2015 at 10:21, Davide D'Alto wrote:
> What's the use case? A user that doesn't want to store the @Id but want it
> to be available when loading the entity?
>
> Davide
>
> On Wed, Oct 7, 2015 at 2:37 AM, Steve Ebersole
> w
What's the use case? A user that doesn't want to store the @Id but want it
to be available when loading the entity?
Davide
On Wed, Oct 7, 2015 at 2:37 AM, Steve Ebersole wrote:
> Votes on supporting this?
>
> https://hibernate.atlassian.net/browse/HHH-9807
>
18 matches
Mail list logo
