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 <rwors...@gmail.com > <mailto:rwors...@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 > <st...@hibernate.org <mailto:st...@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 > <st...@hibernate.org <mailto:st...@hibernate.org> > <mailto: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> > <mailto: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> > <mailto:st...@hibernate.org <mailto:st...@hibernate.org>> > http://hibernate.org > > > > -- > 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
