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