[hibernate-dev] Pull request for HHH-2394 (Support filter tag in subclass)

Rob Worsnop rworsnop at gmail.com
Mon Jun 25 09:29:23 EDT 2012


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 at 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 at 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 at hibernate.org
> http://hibernate.org
>


More information about the hibernate-dev mailing list