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> 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>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>> 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
