Steve,
Thanks for the feedback.
Is this a correct summary:
* Introduce the "{alias}" placeholder, as in Restrictions.sqlRestriction.
* Introduce another optional @Filter element, "entity", which
developers could use instead of the proposed "table" element.
Thanks,
Rob.
On Fri, Jun 1, 2012 at 12:56 PM, Steve Ebersole <st...@hibernate.org> wrote:
> Hi Rob, overall I am OK with the proposal.
>
> Some comments inline
>
> On Thu 31 May 2012 03:32:25 PM CDT, David Mansfield wrote:
>>> It seemed that the challenge to overcome was that Hibernate did not
>>> know which aliases to use when generating the where clauses for
>>> filters. When filters are not allowed on subclasses (current
>>> situation), the alias for the root entity is used for all where
>>> clauses. So when FilterHelper is asked to render the filters, it does
>>> so with a single alias string.
>>
>>> So my changes revolve around two themes:
>>>
>>> 1. Remembering the filter's associated table so that we can generate
>>> an appropriate alias. This was done by replacing the name->condition
>>> map with a list of FilterConfiguration objects. This is a new class
>>> and includes a qualified table name (as well as the name and
>>> condition, of course).
>>>
>>> 2. Passing a callback (instead of the alias string) to
>>> FilterHelper.render() that allows it to generate an appropriate alias
>>> for each filter, depending on table name. The callback is an
>>> implementation of a new interface, FilterAliasGenerator. The
>>> implementation varies by context.
>> The same problem exists in Criteria queries (HHH-1161) when using the
>> sqlRestriction. In that use case, one uses the string '{alias}' as a
>> placeholder in the SQL, and the engine replaces it, however as with your
>> problem, it always replaces with the subclass alias, and therefore
>> cannot be used to create a restriction on any superclass properties.
>>
>> It seems a more generic approach to the '{alias}' syntax which allows
>> for, perhaps, '{entityName.alias}' (e.g.
>> '{com.example.Mammal.alias}.is_pregnant = 1' would work, then your
>> filter conditions wouldn't need the "table" attribute, and the fix would
>> possibly be extensible for HHH-1161.
>
> To be honest, I still think an embedded hint for the alias placement is
> a good idea. There is a lot of chicanery in Hibernate code to try to
> figure out the correct place to put aliases in sql fragments.
> Something like this removes that ambiguity:
>
> @OneToMany(mappedBy="club")
> @Filters({
> @Filter(name="iqMin", table="ZOOLOGY_HUMAN",
> condition="{alias}.HUMAN_IQ >= :min"),
> @Filter(name="pregnantMembers", table="ZOOLOGY_MAMMAL",
> condition="{alias}.IS_PREGNANT=1")
> })
> private Set<Human> members = new HashSet<Human>();
>
> Its really 2 different concerns.
>
>
>> Alternatively, there are already some annotations which take an entity
>> directly (such as @ManyToOne), as a class reference, which is way more
>> typesafe and refactoring friendly. So instead of
>> "table='ZOOLOGY_MAMMAL'" you could have "entity=Mammal.class". This
>> would require more bookeeping on the implementation side, but would be a
>> superior abstraction IMHO.
>
> It would need to allow a mix of both I think. The Class reference is a
> good alternative for inheritance as initially discussed here. But
> another place this comes up is in regards to SecondaryTables, and there
> we would need to know the table name.
>
>
> --
> st...@hibernate.org
> http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
