4:42 p.m.
https://github.com/hibernate/hibernate-orm/pull/339
It seemed that the challenge to overcome was that Hibernate did not
know which aliases to use when generating the where clauses for
filters. When filters are not allowed on subclasses (current
situation), the alias for the root entity is used for all where
clauses. So when FilterHelper is asked to render the filters, it does
so with a single alias string.
So my changes revolve around two themes:
1. Remembering the filter's associated table so that we can generate
an appropriate alias. This was done by replacing the name->condition
map with a list of FilterConfiguration objects. This is a new class
and includes a qualified table name (as well as the name and
condition, of course).
2. Passing a callback (instead of the alias string) to
FilterHelper.render() that allows it to generate an appropriate alias
for each filter, depending on table name. The callback is an
implementation of a new interface, FilterAliasGenerator. The
implementation varies by context.
Where filters are applied to entities, we know the table name. When
filters are applied to collections we do not. My solution to this is
potentially controversial and I'd be interested in hearing
alternatives to it. I have expanded the @Filter annotation to include
a table name. This is an optional element because it makes no sense
when @Filter is applied directly to an entity. That's what I don't
like about this idea.
For example:
@OneToMany(mappedBy="club")
@Filters({
@Filter(name="iqMin", table="ZOOLOGY_HUMAN",
condition="HUMAN_IQ >= :min"),
@Filter(name="pregnantMembers", table="ZOOLOGY_MAMMAL",
condition="IS_PREGNANT=1")
})
private Set<Human> members = new HashSet<Human>();
This is excerpted from here:
https://github.com/rworsnop/hibernate-orm/blob/HHH-2394/hibernate-core/sr...
Thoughts?
3:32 p.m.
I'm no hibernate guru, but I have some comments below:
On 05/30/2012 05:42 PM, Rob Worsnop wrote:
https://github.com/hibernate/hibernate-orm/pull/339
It seemed that the challenge to overcome was that Hibernate did not
know which aliases to use when generating the where clauses for
filters. When filters are not allowed on subclasses (current
situation), the alias for the root entity is used for all where
clauses. So when FilterHelper is asked to render the filters, it does
so with a single alias string.
So my changes revolve around two themes:
1. Remembering the filter's associated table so that we can generate
an appropriate alias. This was done by replacing the name->condition
map with a list of FilterConfiguration objects. This is a new class
and includes a qualified table name (as well as the name and
condition, of course).
2. Passing a callback (instead of the alias string) to
FilterHelper.render() that allows it to generate an appropriate alias
for each filter, depending on table name. The callback is an
implementation of a new interface, FilterAliasGenerator. The
implementation varies by context.
The same problem exists in Criteria queries
(HHH-1161) when using the
sqlRestriction. In that use case, one uses the string '{alias}' as a
placeholder in the SQL, and the engine replaces it, however as with your
problem, it always replaces with the subclass alias, and therefore
cannot be used to create a restriction on any superclass properties.
It seems a more generic approach to the '{alias}' syntax which allows
for, perhaps, '{entityName.alias}' (e.g.
'{com.example.Mammal.alias}.is_pregnant = 1' would work, then your
filter conditions wouldn't need the "table" attribute, and the fix would
possibly be extensible for HHH-1161.
Alternatively, there are already some annotations which take an entity
directly (such as @ManyToOne), as a class reference, which is way more
typesafe and refactoring friendly. So instead of
"table='ZOOLOGY_MAMMAL'" you could have "entity=Mammal.class".
This
would require more bookeeping on the implementation side, but would be a
superior abstraction IMHO.
Where filters are applied to entities, we know the table name. When
filters are applied to collections we do not. My solution to this is
potentially controversial and I'd be interested in hearing
alternatives to it. I have expanded the @Filter annotation to include
a table name. This is an optional element because it makes no sense
when @Filter is applied directly to an entity. That's what I don't
like about this idea.
For example:
@OneToMany(mappedBy="club")
@Filters({
@Filter(name="iqMin", table="ZOOLOGY_HUMAN",
condition="HUMAN_IQ>= :min"),
@Filter(name="pregnantMembers", table="ZOOLOGY_MAMMAL",
condition="IS_PREGNANT=1")
})
private Set<Human> members = new HashSet<Human>();
This is excerpted from here:
https://github.com/rworsnop/hibernate-orm/blob/HHH-2394/hibernate-core/sr...
Thoughts?
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:56 a.m.
Hi Rob, overall I am OK with the proposal.
Some comments inline
On Thu 31 May 2012 03:32:25 PM CDT, David Mansfield wrote:
> It seemed that the challenge to overcome was that Hibernate did
not
> know which aliases to use when generating the where clauses for
> filters. When filters are not allowed on subclasses (current
> situation), the alias for the root entity is used for all where
> clauses. So when FilterHelper is asked to render the filters, it does
> so with a single alias string.
> So my changes revolve around two themes:
>
> 1. Remembering the filter's associated table so that we can generate
> an appropriate alias. This was done by replacing the name->condition
> map with a list of FilterConfiguration objects. This is a new class
> and includes a qualified table name (as well as the name and
> condition, of course).
>
> 2. Passing a callback (instead of the alias string) to
> FilterHelper.render() that allows it to generate an appropriate alias
> for each filter, depending on table name. The callback is an
> implementation of a new interface, FilterAliasGenerator. The
> implementation varies by context.
The same problem exists in Criteria queries (HHH-1161) when using the
sqlRestriction. In that use case, one uses the string '{alias}' as a
placeholder in the SQL, and the engine replaces it, however as with your
problem, it always replaces with the subclass alias, and therefore
cannot be used to create a restriction on any superclass properties.
It seems a more generic approach to the '{alias}' syntax which allows
for, perhaps, '{entityName.alias}' (e.g.
'{com.example.Mammal.alias}.is_pregnant = 1' would work, then your
filter conditions wouldn't need the "table" attribute, and the fix would
possibly be extensible for HHH-1161.
To be honest, I still think an embedded hint for the alias placement is
a good idea. There is a lot of chicanery in Hibernate code to try to
figure out the correct place to put aliases in sql fragments.
Something like this removes that ambiguity:
@OneToMany(mappedBy="club")
@Filters({
@Filter(name="iqMin", table="ZOOLOGY_HUMAN",
condition="{alias}.HUMAN_IQ >= :min"),
@Filter(name="pregnantMembers", table="ZOOLOGY_MAMMAL",
condition="{alias}.IS_PREGNANT=1")
})
private Set<Human> members = new HashSet<Human>();
Its really 2 different concerns.
Alternatively, there are already some annotations which take an
entity
directly (such as @ManyToOne), as a class reference, which is way more
typesafe and refactoring friendly. So instead of
"table='ZOOLOGY_MAMMAL'" you could have
"entity=Mammal.class". This
would require more bookeeping on the implementation side, but would be a
superior abstraction IMHO.
It would need to allow a mix of both I think. The Class reference is a
good alternative for inheritance as initially discussed here. But
another place this comes up is in regards to SecondaryTables, and there
we would need to know the table name.
--
steve(a)hibernate.org
http://hibernate.org
10:07 a.m.
Steve,
Thanks for the feedback.
Is this a correct summary:
* Introduce the "{alias}" placeholder, as in Restrictions.sqlRestriction.
* Introduce another optional @Filter element, "entity", which
developers could use instead of the proposed "table" element.
Thanks,
Rob.
On Fri, Jun 1, 2012 at 12:56 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
Hi Rob, Â overall I am OK with the proposal.
Some comments inline
On Thu 31 May 2012 03:32:25 PM CDT, David Mansfield wrote:
>> It seemed that the challenge to overcome was that Hibernate did not
>> know which aliases to use when generating the where clauses for
>> filters. When filters are not allowed on subclasses (current
>> situation), the alias for the root entity is used for all where
>> clauses. So when FilterHelper is asked to render the filters, it does
>> so with a single alias string.
>
>> So my changes revolve around two themes:
>>
>> 1. Remembering the filter's associated table so that we can generate
>> an appropriate alias. This was done by replacing the name->condition
>> map with a list of FilterConfiguration objects. This is a new class
>> and includes a qualified table name (as well as the name and
>> condition, of course).
>>
>> 2. Passing a callback (instead of the alias string) to
>> FilterHelper.render() that allows it to generate an appropriate alias
>> for each filter, depending on table name. The callback is an
>> implementation of a new interface, FilterAliasGenerator. The
>> implementation varies by context.
> The same problem exists in Criteria queries (HHH-1161) Â when using the
> sqlRestriction. Â In that use case, one uses the string '{alias}' as a
> placeholder in the SQL, and the engine replaces it, however as with your
> problem, it always replaces with the subclass alias, and therefore
> cannot be used to create a restriction on any superclass properties.
>
> It seems a more generic approach to the '{alias}' syntax which allows
> for, perhaps, '{entityName.alias}' (e.g.
> '{com.example.Mammal.alias}.is_pregnant = 1' would work, then your
> filter conditions wouldn't need the "table" attribute, and the fix
would
> possibly be extensible for HHH-1161.
To be honest, I still think an embedded hint for the alias placement is
a good idea. Â There is a lot of chicanery in Hibernate code to try to
figure out the correct place to put aliases in sql fragments.
Something like this removes that ambiguity:
@OneToMany(mappedBy="club")
@Filters({
  @Filter(name="iqMin", table="ZOOLOGY_HUMAN",
condition="{alias}.HUMAN_IQ >= :min"),
  @Filter(name="pregnantMembers", table="ZOOLOGY_MAMMAL",
condition="{alias}.IS_PREGNANT=1")
})
private Set<Human> members = new HashSet<Human>();
Its really 2 different concerns.
> Alternatively, there are already some annotations which take an entity
> directly (such as @ManyToOne), as a class reference, which is way more
> typesafe and refactoring friendly. Â So instead of
> "table='ZOOLOGY_MAMMAL'" you could have
"entity=Mammal.class". Â This
> would require more bookeeping on the implementation side, but would be a
> superior abstraction IMHO.
It would need to allow a mix of both I think. Â The Class reference is a
good alternative for inheritance as initially discussed here. Â But
another place this comes up is in regards to SecondaryTables, and there
we would need to know the table name.
--
steve(a)hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:14 a.m.
1) I think adding support for {alias} is a more general issue. Its
applicable to many other pieces of mapping metadata (@Formula, etc).
More I was responding to David's comment there. I totally think it
makes sense to support this in all of those cases. I guess the vote
point there is whether we want to introduce that support piecemeal or
develop it across the board. If we do do it piecemeal I think another
piece of information we will need is a flag indicating whether to scan
for alias injection points. By "scanning" I mean the processing we do
today where we tokenize the fragment string and then try to guess where
an alias is needed. Let's call this flag 'deduceAliasInjectionPoints'
for now. I tend to favor meaningful attribute names so my suggested
names tend to get a little long; I am open to suggestions for a more
succinct name. Anyway, I think it needs to be TRUE by default to
maintain backwards compatible behavior. Here is an example:
@Filter(name="iqMin", table="ZOOLOGY_HUMAN",
condition="{alias}.HUMAN_IQ >= :min", deduceAliasInjectionPoints=false)
Here there is no need to deduce the points at which to inject an alias;
we have done that for Hibernate in the supplied condition fragment.
I think another discussion revolves around cases in which the fragment
involves references to columns from multiple tables. Mostly this is
important for scenarios involving secondary tables and inheritance. Do
we want to provide support for that? Using the classic
org.hibernate.test.hql.Animal hierarchy from the testsuite, maybe
something like:
@Filter(
name="iqMin",
condition="{a}.bodyWeight >= :minWeight and {m}.birthdate <
:ageCutOffBirthDate",
deduceAliasInjectionPoints=false,
aliases={
@SqlFragmentAlias( alias="a", entity=Animal.class ),
@SqlFragmentAlias( alias="m", entity=Mammal.class )
}
)
NOTE : @SqlFragmentAlias would have support for both 'entity' (as
convenience form) and 'table' attributes.
2) Just wanted to make sure it was clear that I meant that *if* we add
support for 'entity' that it would be an alternative option to 'table'
*in some cases*. There would be times (secondary tables) when 'entity'
would not be useful. Also, I am not overly fond of the term 'entity'.
Its vague here IMHO. I think the attribute name ought to describe
"why". (Yes the term 'entity' is used elsewhere in annotations, but I
think the use there is more meaningful). The thing we are trying to
express here is the "entity hierarchy class whose table is being
referenced". Is that something that is OK to delineate just in
javadoc? Dunno. What does everyone else think? Am I just being too
anal about using the term 'entity' here?
On Mon 04 Jun 2012 10:07:52 AM CDT, Rob Worsnop wrote:
Steve,
Thanks for the feedback.
Is this a correct summary:
* Introduce the "{alias}" placeholder, as in Restrictions.sqlRestriction.
* Introduce another optional @Filter element, "entity", which
developers could use instead of the proposed "table" element.
Thanks,
Rob.
On Fri, Jun 1, 2012 at 12:56 PM, Steve Ebersole<steve(a)hibernate.org> wrote:
> Hi Rob, overall I am OK with the proposal.
>
> Some comments inline
>
> On Thu 31 May 2012 03:32:25 PM CDT, David Mansfield wrote:
>>> It seemed that the challenge to overcome was that Hibernate did not
>>> know which aliases to use when generating the where clauses for
>>> filters. When filters are not allowed on subclasses (current
>>> situation), the alias for the root entity is used for all where
>>> clauses. So when FilterHelper is asked to render the filters, it does
>>> so with a single alias string.
>>
>>> So my changes revolve around two themes:
>>>
>>> 1. Remembering the filter's associated table so that we can generate
>>> an appropriate alias. This was done by replacing the name->condition
>>> map with a list of FilterConfiguration objects. This is a new class
>>> and includes a qualified table name (as well as the name and
>>> condition, of course).
>>>
>>> 2. Passing a callback (instead of the alias string) to
>>> FilterHelper.render() that allows it to generate an appropriate alias
>>> for each filter, depending on table name. The callback is an
>>> implementation of a new interface, FilterAliasGenerator. The
>>> implementation varies by context.
>> The same problem exists in Criteria queries (HHH-1161) when using the
>> sqlRestriction. In that use case, one uses the string '{alias}' as a
>> placeholder in the SQL, and the engine replaces it, however as with your
>> problem, it always replaces with the subclass alias, and therefore
>> cannot be used to create a restriction on any superclass properties.
>>
>> It seems a more generic approach to the '{alias}' syntax which allows
>> for, perhaps, '{entityName.alias}' (e.g.
>> '{com.example.Mammal.alias}.is_pregnant = 1' would work, then your
>> filter conditions wouldn't need the "table" attribute, and the fix
would
>> possibly be extensible for HHH-1161.
>
> To be honest, I still think an embedded hint for the alias placement is
> a good idea. There is a lot of chicanery in Hibernate code to try to
> figure out the correct place to put aliases in sql fragments.
> Something like this removes that ambiguity:
>
> @OneToMany(mappedBy="club")
> @Filters({
> @Filter(name="iqMin", table="ZOOLOGY_HUMAN",
> condition="{alias}.HUMAN_IQ>= :min"),
> @Filter(name="pregnantMembers", table="ZOOLOGY_MAMMAL",
> condition="{alias}.IS_PREGNANT=1")
> })
> private Set<Human> members = new HashSet<Human>();
>
> Its really 2 different concerns.
>
>
>> Alternatively, there are already some annotations which take an entity
>> directly (such as @ManyToOne), as a class reference, which is way more
>> typesafe and refactoring friendly. So instead of
>> "table='ZOOLOGY_MAMMAL'" you could have
"entity=Mammal.class". This
>> would require more bookeeping on the implementation side, but would be a
>> superior abstraction IMHO.
>
> It would need to allow a mix of both I think. The Class reference is a
> good alternative for inheritance as initially discussed here. But
> another place this comes up is in regards to SecondaryTables, and there
> we would need to know the table name.
>
>
> --
> steve(a)hibernate.org
> http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
steve(a)hibernate.org
http://hibernate.org
11:09 a.m.
On Mon, Jun 4, 2012 at 12:14 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
1) I think adding support for {alias} is a more general issue. Â Its
applicable to many other pieces of mapping metadata (@Formula, etc). Â More I
was responding to David's comment there. Â I totally think it makes sense to
support this in all of those cases. Â I guess the vote point there is whether
we want to introduce that support piecemeal or develop it across the board.
 If we do do it piecemeal I think another piece of information we will need
is a flag indicating whether to scan for alias injection points. Â By
"scanning" I mean the processing we do today where we tokenize the fragment
string and then try to guess where an alias is needed. Â Let's call this
flag 'deduceAliasInjectionPoints' for now. Â I tend to favor meaningful
attribute names so my suggested names tend to get a little long; I am open
to suggestions for a more succinct name. Â Anyway, I think it needs to be
TRUE by default to maintain backwards compatible behavior. Â Here is an
example:
@Filter(name="iqMin", table="ZOOLOGY_HUMAN",
condition="{alias}.HUMAN_IQ >=
:min", deduceAliasInjectionPoints=false)
Here there is no need to deduce the points at which to inject an alias; we
have done that for Hibernate in the supplied condition fragment.
I think another discussion revolves around cases in which the fragment
involves references to columns from multiple tables. Â Mostly this is
important for scenarios involving secondary tables and inheritance. Â Do we
want to provide support for that? Â Using the classic
org.hibernate.test.hql.Animal hierarchy from the testsuite, maybe something
like:
@Filter(
 name="iqMin",
 condition="{a}.bodyWeight >= :minWeight and {m}.birthdate <
:ageCutOffBirthDate",
 deduceAliasInjectionPoints=false,
 aliases={
   @SqlFragmentAlias( alias="a", entity=Animal.class ),
   @SqlFragmentAlias( alias="m", entity=Mammal.class )
 }
)
How about just applying the secondary table usage to everything?
So, to rewrite your first example:
@Filter(name="iqMin", condition="{h}.HUMAN_IQ >=> :min",
aliases={@SqlFragmentAlias( alias="h", table="ZOOLOGY_HUMAN" )})
Note that I didn't include "deduceAliasInjectionPoints". Wouldn't we
just infer that from the presence of the aliases element?
7:20 a.m.
'deduceAliasInjectionPoints' is important when you don't have
injections. Otherwise Hibernate ends up scanning the condition
fragment for no reason.
On Fri 22 Jun 2012 11:09:31 AM CDT, Rob Worsnop wrote:
On Mon, Jun 4, 2012 at 12:14 PM, Steve Ebersole
<steve(a)hibernate.org> wrote:
> 1) I think adding support for {alias} is a more general issue. Its
> applicable to many other pieces of mapping metadata (@Formula, etc). More I
> was responding to David's comment there. I totally think it makes sense to
> support this in all of those cases. I guess the vote point there is whether
> we want to introduce that support piecemeal or develop it across the board.
> If we do do it piecemeal I think another piece of information we will need
> is a flag indicating whether to scan for alias injection points. By
> "scanning" I mean the processing we do today where we tokenize the
fragment
> string and then try to guess where an alias is needed. Let's call this
> flag 'deduceAliasInjectionPoints' for now. I tend to favor meaningful
> attribute names so my suggested names tend to get a little long; I am open
> to suggestions for a more succinct name. Anyway, I think it needs to be
> TRUE by default to maintain backwards compatible behavior. Here is an
> example:
>
> @Filter(name="iqMin", table="ZOOLOGY_HUMAN",
condition="{alias}.HUMAN_IQ >=
> :min", deduceAliasInjectionPoints=false)
>
> Here there is no need to deduce the points at which to inject an alias; we
> have done that for Hibernate in the supplied condition fragment.
>
> I think another discussion revolves around cases in which the fragment
> involves references to columns from multiple tables. Mostly this is
> important for scenarios involving secondary tables and inheritance. Do we
> want to provide support for that? Using the classic
> org.hibernate.test.hql.Animal hierarchy from the testsuite, maybe something
> like:
>
> @Filter(
> name="iqMin",
> condition="{a}.bodyWeight >= :minWeight and {m}.birthdate <
> :ageCutOffBirthDate",
> deduceAliasInjectionPoints=false,
> aliases={
> @SqlFragmentAlias( alias="a", entity=Animal.class ),
> @SqlFragmentAlias( alias="m", entity=Mammal.class )
> }
> )
>
How about just applying the secondary table usage to everything?
So, to rewrite your first example:
@Filter(name="iqMin", condition="{h}.HUMAN_IQ >=> :min",
aliases={@SqlFragmentAlias( alias="h", table="ZOOLOGY_HUMAN"
)})
Note that I didn't include "deduceAliasInjectionPoints". Wouldn't we
just infer that from the presence of the aliases element?
--
steve(a)hibernate.org
http://hibernate.org
8:29 a.m.
Got it. Earlier you were looking for suggestions for a less verbose name
for this. How about "autoAliasInjection"?
On Mon, Jun 25, 2012 at 8:20 AM, Steve Ebersole <steve(a)hibernate.org> wrote:
'deduceAliasInjectionPoints' is important when you don't
have injections.
Otherwise Hibernate ends up scanning the condition fragment for no reason.
On Fri 22 Jun 2012 11:09:31 AM CDT, Rob Worsnop wrote:
> On Mon, Jun 4, 2012 at 12:14 PM, Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
>> 1) I think adding support for {alias} is a more general issue. Its
>> applicable to many other pieces of mapping metadata (@Formula, etc).
>> More I
>> was responding to David's comment there. I totally think it makes sense
>> to
>> support this in all of those cases. I guess the vote point there is
>> whether
>> we want to introduce that support piecemeal or develop it across the
>> board.
>> If we do do it piecemeal I think another piece of information we will
>> need
>> is a flag indicating whether to scan for alias injection points. By
>> "scanning" I mean the processing we do today where we tokenize the
>> fragment
>> string and then try to guess where an alias is needed. Let's call this
>> flag 'deduceAliasInjectionPoints' for now. I tend to favor meaningful
>> attribute names so my suggested names tend to get a little long; I am
>> open
>> to suggestions for a more succinct name. Anyway, I think it needs to be
>> TRUE by default to maintain backwards compatible behavior. Here is an
>> example:
>>
>> @Filter(name="iqMin", table="ZOOLOGY_HUMAN",
condition="{alias}.HUMAN_IQ
>> >=
>> :min", deduceAliasInjectionPoints=**false)
>>
>> Here there is no need to deduce the points at which to inject an alias;
>> we
>> have done that for Hibernate in the supplied condition fragment.
>>
>> I think another discussion revolves around cases in which the fragment
>> involves references to columns from multiple tables. Mostly this is
>> important for scenarios involving secondary tables and inheritance. Do
>> we
>> want to provide support for that? Using the classic
>> org.hibernate.test.hql.Animal hierarchy from the testsuite, maybe
>> something
>> like:
>>
>> @Filter(
>> name="iqMin",
>> condition="{a}.bodyWeight >= :minWeight and {m}.birthdate <
>> :ageCutOffBirthDate",
>> deduceAliasInjectionPoints=**false,
>> aliases={
>> @SqlFragmentAlias( alias="a", entity=Animal.class ),
>> @SqlFragmentAlias( alias="m", entity=Mammal.class )
>> }
>> )
>>
>>
> How about just applying the secondary table usage to everything?
>
> So, to rewrite your first example:
>
> @Filter(name="iqMin", condition="{h}.HUMAN_IQ >=> :min",
> aliases={@SqlFragmentAlias( alias="h", table="ZOOLOGY_HUMAN"
)})
>
> Note that I didn't include "deduceAliasInjectionPoints". Wouldn't
we
> just infer that from the presence of the aliases element?
>
--
steve(a)hibernate.org
http://hibernate.org
2:36 p.m.
Rob, were you willing to incorporate these discussed changes into your
pull request?
Personally I think 'autoAliasInjection' is less telling than
'deduceAliasInjectionPoints'. I guess the question is whether it is
still telling enough that users get a sense of what it means just by
name.
On Mon 25 Jun 2012 08:29:23 AM CDT, Rob Worsnop wrote:
Got it. Earlier you were looking for suggestions for a less verbose
name for this. How about "autoAliasInjection"?
On Mon, Jun 25, 2012 at 8:20 AM, Steve Ebersole <steve(a)hibernate.org
<mailto:steve@hibernate.org>> wrote:
'deduceAliasInjectionPoints' is important when you don't have
injections. Otherwise Hibernate ends up scanning the condition
fragment for no reason.
On Fri 22 Jun 2012 11:09:31 AM CDT, Rob Worsnop wrote:
On Mon, Jun 4, 2012 at 12:14 PM, Steve Ebersole
<steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote:
1) I think adding support for {alias} is a more general
issue. Its
applicable to many other pieces of mapping metadata
(@Formula, etc). More I
was responding to David's comment there. I totally think
it makes sense to
support this in all of those cases. I guess the vote
point there is whether
we want to introduce that support piecemeal or develop it
across the board.
If we do do it piecemeal I think another piece of
information we will need
is a flag indicating whether to scan for alias injection
points. By
"scanning" I mean the processing we do today where we
tokenize the fragment
string and then try to guess where an alias is needed.
Let's call this
flag 'deduceAliasInjectionPoints' for now. I tend to
favor meaningful
attribute names so my suggested names tend to get a little
long; I am open
to suggestions for a more succinct name. Anyway, I think
it needs to be
TRUE by default to maintain backwards compatible behavior.
Here is an
example:
@Filter(name="iqMin", table="ZOOLOGY_HUMAN",
condition="{alias}.HUMAN_IQ >=
:min", deduceAliasInjectionPoints=__false)
Here there is no need to deduce the points at which to
inject an alias; we
have done that for Hibernate in the supplied condition
fragment.
I think another discussion revolves around cases in which
the fragment
involves references to columns from multiple tables.
Mostly this is
important for scenarios involving secondary tables and
inheritance. Do we
want to provide support for that? Using the classic
org.hibernate.test.hql.Animal hierarchy from the
testsuite, maybe something
like:
@Filter(
name="iqMin",
condition="{a}.bodyWeight >= :minWeight and {m}.birthdate <
:ageCutOffBirthDate",
deduceAliasInjectionPoints=__false,
aliases={
@SqlFragmentAlias( alias="a", entity=Animal.class ),
@SqlFragmentAlias( alias="m", entity=Mammal.class )
}
)
How about just applying the secondary table usage to everything?
So, to rewrite your first example:
@Filter(name="iqMin", condition="{h}.HUMAN_IQ >=>
:min",
aliases={@SqlFragmentAlias( alias="h",
table="ZOOLOGY_HUMAN" )})
Note that I didn't include "deduceAliasInjectionPoints".
Wouldn't we
just infer that from the presence of the aliases element?
--
steve(a)hibernate.org <mailto:steve@hibernate.org>
http://hibernate.org
--
steve(a)hibernate.org
http://hibernate.org
10:45 p.m.
Yep. Working on it.
Regarding the name, my view is that most developers would need to read the
doc whatever we call it.
On Mon, Jun 25, 2012 at 3:36 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
Rob, were you willing to incorporate these discussed changes into
your
pull request?
Personally I think 'autoAliasInjection' is less telling than
'deduceAliasInjectionPoints'. I guess the question is whether it is still
telling enough that users get a sense of what it means just by name.
On Mon 25 Jun 2012 08:29:23 AM CDT, Rob Worsnop wrote:
> Got it. Earlier you were looking for suggestions for a less verbose
> name for this. How about "autoAliasInjection"?
>
> On Mon, Jun 25, 2012 at 8:20 AM, Steve Ebersole <steve(a)hibernate.org
> <mailto:steve@hibernate.org>> wrote:
>
> 'deduceAliasInjectionPoints' is important when you don't have
> injections. Otherwise Hibernate ends up scanning the condition
> fragment for no reason.
>
>
> On Fri 22 Jun 2012 11:09:31 AM CDT, Rob Worsnop wrote:
>
> On Mon, Jun 4, 2012 at 12:14 PM, Steve Ebersole
> <steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote:
>
> 1) I think adding support for {alias} is a more general
> issue. Its
> applicable to many other pieces of mapping metadata
> (@Formula, etc). More I
> was responding to David's comment there. I totally think
> it makes sense to
> support this in all of those cases. I guess the vote
> point there is whether
> we want to introduce that support piecemeal or develop it
> across the board.
> If we do do it piecemeal I think another piece of
> information we will need
> is a flag indicating whether to scan for alias injection
> points. By
> "scanning" I mean the processing we do today where we
> tokenize the fragment
> string and then try to guess where an alias is needed.
> Let's call this
> flag 'deduceAliasInjectionPoints' for now. I tend to
> favor meaningful
> attribute names so my suggested names tend to get a little
> long; I am open
> to suggestions for a more succinct name. Anyway, I think
> it needs to be
> TRUE by default to maintain backwards compatible behavior.
> Here is an
> example:
>
> @Filter(name="iqMin", table="ZOOLOGY_HUMAN",
> condition="{alias}.HUMAN_IQ >=
> :min", deduceAliasInjectionPoints=__**false)
>
>
> Here there is no need to deduce the points at which to
> inject an alias; we
> have done that for Hibernate in the supplied condition
> fragment.
>
> I think another discussion revolves around cases in which
> the fragment
> involves references to columns from multiple tables.
> Mostly this is
> important for scenarios involving secondary tables and
> inheritance. Do we
> want to provide support for that? Using the classic
> org.hibernate.test.hql.Animal hierarchy from the
> testsuite, maybe something
> like:
>
> @Filter(
> name="iqMin",
> condition="{a}.bodyWeight >= :minWeight and {m}.birthdate <
> :ageCutOffBirthDate",
> deduceAliasInjectionPoints=__**false,
>
> aliases={
> @SqlFragmentAlias( alias="a", entity=Animal.class ),
> @SqlFragmentAlias( alias="m", entity=Mammal.class )
> }
> )
>
>
> How about just applying the secondary table usage to everything?
>
> So, to rewrite your first example:
>
> @Filter(name="iqMin", condition="{h}.HUMAN_IQ >=>
:min",
> aliases={@SqlFragmentAlias( alias="h",
> table="ZOOLOGY_HUMAN" )})
>
> Note that I didn't include "deduceAliasInjectionPoints".
> Wouldn't we
> just infer that from the presence of the aliases element?
>
>
> --
> steve(a)hibernate.org <mailto:steve@hibernate.org>
> http://hibernate.org
>
>
>
--
steve(a)hibernate.org
http://hibernate.org
2:40 p.m.
And by the way, I think you are right in that if there are any explicit
SqlFragmentAlias bits supplied, that we infer
'deduceAliasInjectionPoints' as being false.
On 06/25/2012 08:29 AM, Rob Worsnop wrote:
Got it. Earlier you were looking for suggestions for a less verbose
name
for this. How about "autoAliasInjection"?
On Mon, Jun 25, 2012 at 8:20 AM, Steve Ebersole <steve(a)hibernate.org
<mailto:steve@hibernate.org>> wrote:
'deduceAliasInjectionPoints' is important when you don't have
injections. Otherwise Hibernate ends up scanning the condition
fragment for no reason.
On Fri 22 Jun 2012 11:09:31 AM CDT, Rob Worsnop wrote:
On Mon, Jun 4, 2012 at 12:14 PM, Steve Ebersole
<steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote:
1) I think adding support for {alias} is a more general
issue. Its
applicable to many other pieces of mapping metadata
(@Formula, etc). More I
was responding to David's comment there. I totally think it
makes sense to
support this in all of those cases. I guess the vote point
there is whether
we want to introduce that support piecemeal or develop it
across the board.
If we do do it piecemeal I think another piece of
information we will need
is a flag indicating whether to scan for alias injection
points. By
"scanning" I mean the processing we do today where we
tokenize the fragment
string and then try to guess where an alias is needed.
Let's call this
flag 'deduceAliasInjectionPoints' for now. I tend to favor
meaningful
attribute names so my suggested names tend to get a little
long; I am open
to suggestions for a more succinct name. Anyway, I think it
needs to be
TRUE by default to maintain backwards compatible behavior.
Here is an
example:
@Filter(name="iqMin", table="ZOOLOGY_HUMAN",
condition="{alias}.HUMAN_IQ >=
:min", deduceAliasInjectionPoints=__false)
Here there is no need to deduce the points at which to
inject an alias; we
have done that for Hibernate in the supplied condition fragment.
I think another discussion revolves around cases in which
the fragment
involves references to columns from multiple tables. Mostly
this is
important for scenarios involving secondary tables and
inheritance. Do we
want to provide support for that? Using the classic
org.hibernate.test.hql.Animal hierarchy from the testsuite,
maybe something
like:
@Filter(
name="iqMin",
condition="{a}.bodyWeight >= :minWeight and {m}.birthdate <
:ageCutOffBirthDate",
deduceAliasInjectionPoints=__false,
aliases={
@SqlFragmentAlias( alias="a", entity=Animal.class ),
@SqlFragmentAlias( alias="m", entity=Mammal.class )
}
)
How about just applying the secondary table usage to everything?
So, to rewrite your first example:
@Filter(name="iqMin", condition="{h}.HUMAN_IQ >=>
:min",
aliases={@SqlFragmentAlias( alias="h",
table="ZOOLOGY_HUMAN" )})
Note that I didn't include "deduceAliasInjectionPoints".
Wouldn't we
just infer that from the presence of the aliases element?
--
steve(a)hibernate.org <mailto:steve@hibernate.org>
http://hibernate.org
--
steve(a)hibernate.org
http://hibernate.org
10:48 p.m.
Oh good. The way I am coding it, the flag will be ignored
if SqlFragmentAlias elements are present.
On Mon, Jun 25, 2012 at 3:40 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
And by the way, I think you are right in that if there are any
explicit
SqlFragmentAlias bits supplied, that we infer 'deduceAliasInjectionPoints'
as being false.
On 06/25/2012 08:29 AM, Rob Worsnop wrote:
> Got it. Earlier you were looking for suggestions for a less verbose name
> for this. How about "autoAliasInjection"?
>
> On Mon, Jun 25, 2012 at 8:20 AM, Steve Ebersole <steve(a)hibernate.org
> <mailto:steve@hibernate.org>> wrote:
>
> 'deduceAliasInjectionPoints' is important when you don't have
> injections. Otherwise Hibernate ends up scanning the condition
> fragment for no reason.
>
>
> On Fri 22 Jun 2012 11:09:31 AM CDT, Rob Worsnop wrote:
>
> On Mon, Jun 4, 2012 at 12:14 PM, Steve Ebersole
> <steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote:
>
> 1) I think adding support for {alias} is a more general
> issue. Its
> applicable to many other pieces of mapping metadata
> (@Formula, etc). More I
> was responding to David's comment there. I totally think it
> makes sense to
> support this in all of those cases. I guess the vote point
> there is whether
> we want to introduce that support piecemeal or develop it
> across the board.
> If we do do it piecemeal I think another piece of
> information we will need
> is a flag indicating whether to scan for alias injection
> points. By
> "scanning" I mean the processing we do today where we
> tokenize the fragment
> string and then try to guess where an alias is needed.
> Let's call this
> flag 'deduceAliasInjectionPoints' for now. I tend to favor
> meaningful
> attribute names so my suggested names tend to get a little
> long; I am open
> to suggestions for a more succinct name. Anyway, I think it
> needs to be
> TRUE by default to maintain backwards compatible behavior.
> Here is an
> example:
>
> @Filter(name="iqMin", table="ZOOLOGY_HUMAN",
> condition="{alias}.HUMAN_IQ >=
> :min", deduceAliasInjectionPoints=__**false)
>
>
> Here there is no need to deduce the points at which to
> inject an alias; we
> have done that for Hibernate in the supplied condition
> fragment.
>
> I think another discussion revolves around cases in which
> the fragment
> involves references to columns from multiple tables. Mostly
> this is
> important for scenarios involving secondary tables and
> inheritance. Do we
> want to provide support for that? Using the classic
> org.hibernate.test.hql.Animal hierarchy from the testsuite,
> maybe something
> like:
>
> @Filter(
> name="iqMin",
> condition="{a}.bodyWeight >= :minWeight and {m}.birthdate <
> :ageCutOffBirthDate",
> deduceAliasInjectionPoints=__**false,
>
> aliases={
> @SqlFragmentAlias( alias="a", entity=Animal.class ),
> @SqlFragmentAlias( alias="m", entity=Mammal.class )
> }
> )
>
>
> How about just applying the secondary table usage to everything?
>
> So, to rewrite your first example:
>
> @Filter(name="iqMin", condition="{h}.HUMAN_IQ >=>
:min",
> aliases={@SqlFragmentAlias( alias="h",
> table="ZOOLOGY_HUMAN" )})
>
> Note that I didn't include "deduceAliasInjectionPoints".
Wouldn't
> we
> just infer that from the presence of the aliases element?
>
>
> --
> steve(a)hibernate.org <mailto:steve@hibernate.org>
> http://hibernate.org
>
>
>
--
steve(a)hibernate.org
http://hibernate.org
1:04 p.m.
OK, done. I think I covered everything.
Assuming my changes are OK, will they be in 4.2?
On Mon, Jun 25, 2012 at 11:48 PM, Rob Worsnop <rworsnop(a)gmail.com> wrote:
Oh good. The way I am coding it, the flag will be ignored
if SqlFragmentAlias elements are present.
On Mon, Jun 25, 2012 at 3:40 PM, Steve Ebersole <steve(a)hibernate.org>wrote:
> And by the way, I think you are right in that if there are any explicit
> SqlFragmentAlias bits supplied, that we infer 'deduceAliasInjectionPoints'
> as being false.
>
>
> On 06/25/2012 08:29 AM, Rob Worsnop wrote:
>
>> Got it. Earlier you were looking for suggestions for a less verbose name
>> for this. How about "autoAliasInjection"?
>>
>> On Mon, Jun 25, 2012 at 8:20 AM, Steve Ebersole <steve(a)hibernate.org
>> <mailto:steve@hibernate.org>> wrote:
>>
>> 'deduceAliasInjectionPoints' is important when you don't have
>> injections. Otherwise Hibernate ends up scanning the condition
>> fragment for no reason.
>>
>>
>> On Fri 22 Jun 2012 11:09:31 AM CDT, Rob Worsnop wrote:
>>
>> On Mon, Jun 4, 2012 at 12:14 PM, Steve Ebersole
>> <steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote:
>>
>> 1) I think adding support for {alias} is a more general
>> issue. Its
>> applicable to many other pieces of mapping metadata
>> (@Formula, etc). More I
>> was responding to David's comment there. I totally think it
>> makes sense to
>> support this in all of those cases. I guess the vote point
>> there is whether
>> we want to introduce that support piecemeal or develop it
>> across the board.
>> If we do do it piecemeal I think another piece of
>> information we will need
>> is a flag indicating whether to scan for alias injection
>> points. By
>> "scanning" I mean the processing we do today where we
>> tokenize the fragment
>> string and then try to guess where an alias is needed.
>> Let's call this
>> flag 'deduceAliasInjectionPoints' for now. I tend to favor
>> meaningful
>> attribute names so my suggested names tend to get a little
>> long; I am open
>> to suggestions for a more succinct name. Anyway, I think it
>> needs to be
>> TRUE by default to maintain backwards compatible behavior.
>> Here is an
>> example:
>>
>> @Filter(name="iqMin", table="ZOOLOGY_HUMAN",
>> condition="{alias}.HUMAN_IQ >=
>> :min", deduceAliasInjectionPoints=__**false)
>>
>>
>> Here there is no need to deduce the points at which to
>> inject an alias; we
>> have done that for Hibernate in the supplied condition
>> fragment.
>>
>> I think another discussion revolves around cases in which
>> the fragment
>> involves references to columns from multiple tables. Mostly
>> this is
>> important for scenarios involving secondary tables and
>> inheritance. Do we
>> want to provide support for that? Using the classic
>> org.hibernate.test.hql.Animal hierarchy from the testsuite,
>> maybe something
>> like:
>>
>> @Filter(
>> name="iqMin",
>> condition="{a}.bodyWeight >= :minWeight and {m}.birthdate
<
>> :ageCutOffBirthDate",
>> deduceAliasInjectionPoints=__**false,
>>
>> aliases={
>> @SqlFragmentAlias( alias="a", entity=Animal.class ),
>> @SqlFragmentAlias( alias="m", entity=Mammal.class )
>> }
>> )
>>
>>
>> How about just applying the secondary table usage to everything?
>>
>> So, to rewrite your first example:
>>
>> @Filter(name="iqMin", condition="{h}.HUMAN_IQ >=>
:min",
>> aliases={@SqlFragmentAlias( alias="h",
>> table="ZOOLOGY_HUMAN" )})
>>
>> Note that I didn't include "deduceAliasInjectionPoints".
Wouldn't
>> we
>> just infer that from the presence of the aliases element?
>>
>>
>> --
>> steve(a)hibernate.org <mailto:steve@hibernate.org>
>> http://hibernate.org
>>
>>
>>
> --
> steve(a)hibernate.org
> http://hibernate.org
>
>
>
1:55 p.m.
The plan as of now is to not have a 4.2.
Your changes will be in 4.1.5 (if ok).
On Thu 28 Jun 2012 01:04:42 PM CDT, Rob Worsnop wrote:
OK, done. I think I covered everything.
Assuming my changes are OK, will they be in 4.2?
On Mon, Jun 25, 2012 at 11:48 PM, Rob Worsnop <rworsnop(a)gmail.com
<mailto:rworsnop@gmail.com>> wrote:
Oh good. The way I am coding it, the flag will be ignored
if SqlFragmentAlias elements are present.
On Mon, Jun 25, 2012 at 3:40 PM, Steve Ebersole
<steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote:
And by the way, I think you are right in that if there are any
explicit SqlFragmentAlias bits supplied, that we infer
'deduceAliasInjectionPoints' as being false.
On 06/25/2012 08:29 AM, Rob Worsnop wrote:
Got it. Earlier you were looking for suggestions for a
less verbose name
for this. How about "autoAliasInjection"?
On Mon, Jun 25, 2012 at 8:20 AM, Steve Ebersole
<steve(a)hibernate.org <mailto:steve@hibernate.org>
<mailto:steve@hibernate.org <mailto:steve@hibernate.org>>>
wrote:
'deduceAliasInjectionPoints' is important when you
don't have
injections. Otherwise Hibernate ends up scanning the
condition
fragment for no reason.
On Fri 22 Jun 2012 11:09:31 AM CDT, Rob Worsnop wrote:
On Mon, Jun 4, 2012 at 12:14 PM, Steve Ebersole
<steve(a)hibernate.org <mailto:steve@hibernate.org>
<mailto:steve@hibernate.org <mailto:steve@hibernate.org>>>
wrote:
1) I think adding support for {alias} is a more
general
issue. Its
applicable to many other pieces of mapping metadata
(@Formula, etc). More I
was responding to David's comment there. I
totally think it
makes sense to
support this in all of those cases. I guess
the vote point
there is whether
we want to introduce that support piecemeal or
develop it
across the board.
If we do do it piecemeal I think another piece of
information we will need
is a flag indicating whether to scan for alias
injection
points. By
"scanning" I mean the processing we do today
where we
tokenize the fragment
string and then try to guess where an alias is
needed.
Let's call this
flag 'deduceAliasInjectionPoints' for now. I
tend to favor
meaningful
attribute names so my suggested names tend to
get a little
long; I am open
to suggestions for a more succinct name.
Anyway, I think it
needs to be
TRUE by default to maintain backwards
compatible behavior.
Here is an
example:
@Filter(name="iqMin", table="ZOOLOGY_HUMAN",
condition="{alias}.HUMAN_IQ >=
:min", deduceAliasInjectionPoints=____false)
Here there is no need to deduce the points at
which to
inject an alias; we
have done that for Hibernate in the supplied
condition fragment.
I think another discussion revolves around
cases in which
the fragment
involves references to columns from multiple
tables. Mostly
this is
important for scenarios involving secondary
tables and
inheritance. Do we
want to provide support for that? Using the
classic
org.hibernate.test.hql.Animal hierarchy from
the testsuite,
maybe something
like:
@Filter(
name="iqMin",
condition="{a}.bodyWeight >= :minWeight and
{m}.birthdate <
:ageCutOffBirthDate",
deduceAliasInjectionPoints=____false,
aliases={
@SqlFragmentAlias( alias="a",
entity=Animal.class ),
@SqlFragmentAlias( alias="m",
entity=Mammal.class )
}
)
How about just applying the secondary table usage
to everything?
So, to rewrite your first example:
@Filter(name="iqMin", condition="{h}.HUMAN_IQ
>=>
:min",
aliases={@SqlFragmentAlias( alias="h",
table="ZOOLOGY_HUMAN" )})
Note that I didn't include
"deduceAliasInjectionPoints". Wouldn't we
just infer that from the presence of the aliases
element?
--
steve(a)hibernate.org <mailto:steve@hibernate.org>
<mailto:steve@hibernate.org <mailto:steve@hibernate.org>>
http://hibernate.org
--
steve(a)hibernate.org <mailto:steve@hibernate.org>
http://hibernate.org
--
steve(a)hibernate.org
http://hibernate.org
8:52 a.m.
Rob, I apologize. This was missed in the 4.1.5 release.
On Thu 28 Jun 2012 01:55:53 PM CDT, Steve Ebersole wrote:
The plan as of now is to not have a 4.2.
Your changes will be in 4.1.5 (if ok).
On Thu 28 Jun 2012 01:04:42 PM CDT, Rob Worsnop wrote:
> OK, done. I think I covered everything.
>
> Assuming my changes are OK, will they be in 4.2?
>
> On Mon, Jun 25, 2012 at 11:48 PM, Rob Worsnop <rworsnop(a)gmail.com
> <mailto:rworsnop@gmail.com>> wrote:
>
> Oh good. The way I am coding it, the flag will be ignored
> if SqlFragmentAlias elements are present.
>
>
> On Mon, Jun 25, 2012 at 3:40 PM, Steve Ebersole
> <steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote:
>
> And by the way, I think you are right in that if there are any
> explicit SqlFragmentAlias bits supplied, that we infer
> 'deduceAliasInjectionPoints' as being false.
>
>
> On 06/25/2012 08:29 AM, Rob Worsnop wrote:
>
> Got it. Earlier you were looking for suggestions for a
> less verbose name
> for this. How about "autoAliasInjection"?
>
> On Mon, Jun 25, 2012 at 8:20 AM, Steve Ebersole
> <steve(a)hibernate.org <mailto:steve@hibernate.org>
> <mailto:steve@hibernate.org
<mailto:steve@hibernate.org>>>
> wrote:
>
> 'deduceAliasInjectionPoints' is important when you
> don't have
> injections. Otherwise Hibernate ends up scanning the
> condition
> fragment for no reason.
>
>
> On Fri 22 Jun 2012 11:09:31 AM CDT, Rob Worsnop wrote:
>
> On Mon, Jun 4, 2012 at 12:14 PM, Steve Ebersole
> <steve(a)hibernate.org <mailto:steve@hibernate.org>
> <mailto:steve@hibernate.org
<mailto:steve@hibernate.org>>>
> wrote:
>
> 1) I think adding support for {alias} is a more
> general
> issue. Its
> applicable to many other pieces of mapping
> metadata
> (@Formula, etc). More I
> was responding to David's comment there. I
> totally think it
> makes sense to
> support this in all of those cases. I guess
> the vote point
> there is whether
> we want to introduce that support piecemeal or
> develop it
> across the board.
> If we do do it piecemeal I think another
> piece of
> information we will need
> is a flag indicating whether to scan for alias
> injection
> points. By
> "scanning" I mean the processing we do today
> where we
> tokenize the fragment
> string and then try to guess where an alias is
> needed.
> Let's call this
> flag 'deduceAliasInjectionPoints' for now. I
> tend to favor
> meaningful
> attribute names so my suggested names tend to
> get a little
> long; I am open
> to suggestions for a more succinct name.
> Anyway, I think it
> needs to be
> TRUE by default to maintain backwards
> compatible behavior.
> Here is an
> example:
>
> @Filter(name="iqMin",
table="ZOOLOGY_HUMAN",
> condition="{alias}.HUMAN_IQ >=
> :min", deduceAliasInjectionPoints=____false)
>
>
> Here there is no need to deduce the points at
> which to
> inject an alias; we
> have done that for Hibernate in the supplied
> condition fragment.
>
> I think another discussion revolves around
> cases in which
> the fragment
> involves references to columns from multiple
> tables. Mostly
> this is
> important for scenarios involving secondary
> tables and
> inheritance. Do we
> want to provide support for that? Using the
> classic
> org.hibernate.test.hql.Animal hierarchy from
> the testsuite,
> maybe something
> like:
>
> @Filter(
> name="iqMin",
> condition="{a}.bodyWeight >= :minWeight and
> {m}.birthdate <
> :ageCutOffBirthDate",
> deduceAliasInjectionPoints=____false,
>
> aliases={
> @SqlFragmentAlias( alias="a",
> entity=Animal.class ),
> @SqlFragmentAlias( alias="m",
> entity=Mammal.class )
> }
> )
>
>
> How about just applying the secondary table usage
> to everything?
>
> So, to rewrite your first example:
>
> @Filter(name="iqMin", condition="{h}.HUMAN_IQ
>=>
> :min",
> aliases={@SqlFragmentAlias( alias="h",
> table="ZOOLOGY_HUMAN" )})
>
> Note that I didn't include
> "deduceAliasInjectionPoints". Wouldn't we
> just infer that from the presence of the aliases
> element?
>
>
> --
> steve(a)hibernate.org <mailto:steve@hibernate.org>
> <mailto:steve@hibernate.org <mailto:steve@hibernate.org>>
> http://hibernate.org
>
>
>
> --
> steve(a)hibernate.org <mailto:steve@hibernate.org>
> http://hibernate.org
>
>
>
>
--
steve(a)hibernate.org
http://hibernate.org
--
steve(a)hibernate.org
http://hibernate.org
4:18 p.m.
It did make it into the 4.1.5.SP1 however :)
On Thu 12 Jul 2012 08:52:43 AM CDT, Steve Ebersole wrote:
Rob, I apologize. This was missed in the 4.1.5 release.
On Thu 28 Jun 2012 01:55:53 PM CDT, Steve Ebersole wrote:
> The plan as of now is to not have a 4.2.
>
> Your changes will be in 4.1.5 (if ok).
>
> On Thu 28 Jun 2012 01:04:42 PM CDT, Rob Worsnop wrote:
>> OK, done. I think I covered everything.
>>
>> Assuming my changes are OK, will they be in 4.2?
>>
>> On Mon, Jun 25, 2012 at 11:48 PM, Rob Worsnop <rworsnop(a)gmail.com
>> <mailto:rworsnop@gmail.com>> wrote:
>>
>> Oh good. The way I am coding it, the flag will be ignored
>> if SqlFragmentAlias elements are present.
>>
>>
>> On Mon, Jun 25, 2012 at 3:40 PM, Steve Ebersole
>> <steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote:
>>
>> And by the way, I think you are right in that if there are any
>> explicit SqlFragmentAlias bits supplied, that we infer
>> 'deduceAliasInjectionPoints' as being false.
>>
>>
>> On 06/25/2012 08:29 AM, Rob Worsnop wrote:
>>
>> Got it. Earlier you were looking for suggestions for a
>> less verbose name
>> for this. How about "autoAliasInjection"?
>>
>> On Mon, Jun 25, 2012 at 8:20 AM, Steve Ebersole
>> <steve(a)hibernate.org <mailto:steve@hibernate.org>
>> <mailto:steve@hibernate.org
<mailto:steve@hibernate.org>>>
>> wrote:
>>
>> 'deduceAliasInjectionPoints' is important when you
>> don't have
>> injections. Otherwise Hibernate ends up scanning the
>> condition
>> fragment for no reason.
>>
>>
>> On Fri 22 Jun 2012 11:09:31 AM CDT, Rob Worsnop wrote:
>>
>> On Mon, Jun 4, 2012 at 12:14 PM, Steve Ebersole
>> <steve(a)hibernate.org <mailto:steve@hibernate.org>
>> <mailto:steve@hibernate.org
<mailto:steve@hibernate.org>>>
>> wrote:
>>
>> 1) I think adding support for {alias} is a more
>> general
>> issue. Its
>> applicable to many other pieces of mapping
>> metadata
>> (@Formula, etc). More I
>> was responding to David's comment there. I
>> totally think it
>> makes sense to
>> support this in all of those cases. I guess
>> the vote point
>> there is whether
>> we want to introduce that support piecemeal or
>> develop it
>> across the board.
>> If we do do it piecemeal I think another
>> piece of
>> information we will need
>> is a flag indicating whether to scan for alias
>> injection
>> points. By
>> "scanning" I mean the processing we do today
>> where we
>> tokenize the fragment
>> string and then try to guess where an alias is
>> needed.
>> Let's call this
>> flag 'deduceAliasInjectionPoints' for now. I
>> tend to favor
>> meaningful
>> attribute names so my suggested names tend to
>> get a little
>> long; I am open
>> to suggestions for a more succinct name.
>> Anyway, I think it
>> needs to be
>> TRUE by default to maintain backwards
>> compatible behavior.
>> Here is an
>> example:
>>
>> @Filter(name="iqMin",
table="ZOOLOGY_HUMAN",
>> condition="{alias}.HUMAN_IQ >=
>> :min", deduceAliasInjectionPoints=____false)
>>
>>
>> Here there is no need to deduce the points at
>> which to
>> inject an alias; we
>> have done that for Hibernate in the supplied
>> condition fragment.
>>
>> I think another discussion revolves around
>> cases in which
>> the fragment
>> involves references to columns from multiple
>> tables. Mostly
>> this is
>> important for scenarios involving secondary
>> tables and
>> inheritance. Do we
>> want to provide support for that? Using the
>> classic
>> org.hibernate.test.hql.Animal hierarchy from
>> the testsuite,
>> maybe something
>> like:
>>
>> @Filter(
>> name="iqMin",
>> condition="{a}.bodyWeight >= :minWeight and
>> {m}.birthdate <
>> :ageCutOffBirthDate",
>> deduceAliasInjectionPoints=____false,
>>
>> aliases={
>> @SqlFragmentAlias( alias="a",
>> entity=Animal.class ),
>> @SqlFragmentAlias( alias="m",
>> entity=Mammal.class )
>> }
>> )
>>
>>
>> How about just applying the secondary table usage
>> to everything?
>>
>> So, to rewrite your first example:
>>
>> @Filter(name="iqMin", condition="{h}.HUMAN_IQ
>=>
>> :min",
>> aliases={@SqlFragmentAlias( alias="h",
>> table="ZOOLOGY_HUMAN" )})
>>
>> Note that I didn't include
>> "deduceAliasInjectionPoints". Wouldn't we
>> just infer that from the presence of the aliases
>> element?
>>
>>
>> --
>> steve(a)hibernate.org <mailto:steve@hibernate.org>
>> <mailto:steve@hibernate.org
<mailto:steve@hibernate.org>>
>> http://hibernate.org
>>
>>
>>
>> --
>> steve(a)hibernate.org <mailto:steve@hibernate.org>
>> http://hibernate.org
>>
>>
>>
>>
>
> --
> steve(a)hibernate.org
> http://hibernate.org
--
steve(a)hibernate.org
http://hibernate.org
--
steve(a)hibernate.org
http://hibernate.org
4:51 p.m.
Saw that. Thanks!
On Thu, Jul 12, 2012 at 5:18 PM, Steve Ebersole <steve(a)hibernate.org> wrote:
It did make it into the 4.1.5.SP1 however :)
On Thu 12 Jul 2012 08:52:43 AM CDT, Steve Ebersole wrote:
> Rob, I apologize. This was missed in the 4.1.5 release.
>
> On Thu 28 Jun 2012 01:55:53 PM CDT, Steve Ebersole wrote:
>
>> The plan as of now is to not have a 4.2.
>>
>> Your changes will be in 4.1.5 (if ok).
>>
>> On Thu 28 Jun 2012 01:04:42 PM CDT, Rob Worsnop wrote:
>>
>>> OK, done. I think I covered everything.
>>>
>>> Assuming my changes are OK, will they be in 4.2?
>>>
>>> On Mon, Jun 25, 2012 at 11:48 PM, Rob Worsnop <rworsnop(a)gmail.com
>>> <mailto:rworsnop@gmail.com>> wrote:
>>>
>>> Oh good. The way I am coding it, the flag will be ignored
>>> if SqlFragmentAlias elements are present.
>>>
>>>
>>> On Mon, Jun 25, 2012 at 3:40 PM, Steve Ebersole
>>> <steve(a)hibernate.org <mailto:steve@hibernate.org>> wrote:
>>>
>>> And by the way, I think you are right in that if there are any
>>> explicit SqlFragmentAlias bits supplied, that we infer
>>> 'deduceAliasInjectionPoints' as being false.
>>>
>>>
>>> On 06/25/2012 08:29 AM, Rob Worsnop wrote:
>>>
>>> Got it. Earlier you were looking for suggestions for a
>>> less verbose name
>>> for this. How about "autoAliasInjection"?
>>>
>>> On Mon, Jun 25, 2012 at 8:20 AM, Steve Ebersole
>>> <steve(a)hibernate.org <mailto:steve@hibernate.org>
>>> <mailto:steve@hibernate.org
<mailto:steve@hibernate.org>>>
>>> wrote:
>>>
>>> 'deduceAliasInjectionPoints' is important when you
>>> don't have
>>> injections. Otherwise Hibernate ends up scanning the
>>> condition
>>> fragment for no reason.
>>>
>>>
>>> On Fri 22 Jun 2012 11:09:31 AM CDT, Rob Worsnop wrote:
>>>
>>> On Mon, Jun 4, 2012 at 12:14 PM, Steve Ebersole
>>> <steve(a)hibernate.org
<mailto:steve@hibernate.org>
>>> <mailto:steve@hibernate.org
<mailto:steve@hibernate.org>>>
>>> wrote:
>>>
>>> 1) I think adding support for {alias} is a more
>>> general
>>> issue. Its
>>> applicable to many other pieces of mapping
>>> metadata
>>> (@Formula, etc). More I
>>> was responding to David's comment there. I
>>> totally think it
>>> makes sense to
>>> support this in all of those cases. I guess
>>> the vote point
>>> there is whether
>>> we want to introduce that support piecemeal or
>>> develop it
>>> across the board.
>>> If we do do it piecemeal I think another
>>> piece of
>>> information we will need
>>> is a flag indicating whether to scan for alias
>>> injection
>>> points. By
>>> "scanning" I mean the processing we do
today
>>> where we
>>> tokenize the fragment
>>> string and then try to guess where an alias is
>>> needed.
>>> Let's call this
>>> flag 'deduceAliasInjectionPoints' for now. I
>>> tend to favor
>>> meaningful
>>> attribute names so my suggested names tend to
>>> get a little
>>> long; I am open
>>> to suggestions for a more succinct name.
>>> Anyway, I think it
>>> needs to be
>>> TRUE by default to maintain backwards
>>> compatible behavior.
>>> Here is an
>>> example:
>>>
>>> @Filter(name="iqMin",
table="ZOOLOGY_HUMAN",
>>> condition="{alias}.HUMAN_IQ >=
>>> :min", deduceAliasInjectionPoints=___**_false)
>>>
>>>
>>> Here there is no need to deduce the points at
>>> which to
>>> inject an alias; we
>>> have done that for Hibernate in the supplied
>>> condition fragment.
>>>
>>> I think another discussion revolves around
>>> cases in which
>>> the fragment
>>> involves references to columns from multiple
>>> tables. Mostly
>>> this is
>>> important for scenarios involving secondary
>>> tables and
>>> inheritance. Do we
>>> want to provide support for that? Using the
>>> classic
>>> org.hibernate.test.hql.Animal hierarchy from
>>> the testsuite,
>>> maybe something
>>> like:
>>>
>>> @Filter(
>>> name="iqMin",
>>> condition="{a}.bodyWeight >= :minWeight
and
>>> {m}.birthdate <
>>> :ageCutOffBirthDate",
>>> deduceAliasInjectionPoints=___**_false,
>>>
>>> aliases={
>>> @SqlFragmentAlias( alias="a",
>>> entity=Animal.class ),
>>> @SqlFragmentAlias( alias="m",
>>> entity=Mammal.class )
>>> }
>>> )
>>>
>>>
>>> How about just applying the secondary table usage
>>> to everything?
>>>
>>> So, to rewrite your first example:
>>>
>>> @Filter(name="iqMin",
condition="{h}.HUMAN_IQ >=>
>>> :min",
>>> aliases={@SqlFragmentAlias( alias="h",
>>> table="ZOOLOGY_HUMAN" )})
>>>
>>> Note that I didn't include
>>> "deduceAliasInjectionPoints". Wouldn't we
>>> just infer that from the presence of the aliases
>>> element?
>>>
>>>
>>> --
>>> steve(a)hibernate.org <mailto:steve@hibernate.org>
>>> <mailto:steve@hibernate.org
<mailto:steve@hibernate.org>>
>>> http://hibernate.org
>>>
>>>
>>>
>>> --
>>> steve(a)hibernate.org <mailto:steve@hibernate.org>
>>> http://hibernate.org
>>>
>>>
>>>
>>>
>>>
>> --
>> steve(a)hibernate.org
>> http://hibernate.org
>>
>
> --
> steve(a)hibernate.org
> http://hibernate.org
>
--
steve(a)hibernate.org
http://hibernate.org
4515
days inactive
4558
days old
16 comments
3 participants
participants (3)
-
David Mansfield -
Rob Worsnop -
Steve Ebersole