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 <st...@hibernate.org > <mailto:st...@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 > <st...@hibernate.org <mailto:st...@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? > > > -- > st...@hibernate.org <mailto:st...@hibernate.org> > http://hibernate.org > > -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
