Rob, I apologize. This was missed in the 4.1.5 release. On Thu 28 Jun 2012 01:55:53 PM CDT, Steve Ebersole wrote: > 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
-- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
