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

[Steve Ebersole]

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 at gmail.com
> <mailto:rworsnop at 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 at hibernate.org <mailto:steve at 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 at hibernate.org <mailto:steve at hibernate.org>
>             <mailto:steve at hibernate.org <mailto: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 <mailto:steve at hibernate.org>
>             <mailto:steve at hibernate.org <mailto: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 <mailto:steve at hibernate.org>
>             <mailto:steve at hibernate.org <mailto:steve at hibernate.org>>
>             http://hibernate.org
>
>
>
>         --
>         steve at hibernate.org <mailto:steve at hibernate.org>
>         http://hibernate.org
>
>
>
>

--
steve at hibernate.org
http://hibernate.org