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