I would like to be able to filter many-to-one relationships.

The reason for this is that I have two tables (parent and child) with bi-directional "one to many" - "many to one" relationship between them. However this is only true when a filter is applied.
When the filter is disabled the relationship becomes a:

many-to-one-to-many

Where the "one" is a phantom table that doesn't exist.

Anyway I have applied filters at the class level for both the parent and child. Additionally I have defined the filter as part of the relationship from the parent to child (one-to-many) and they all work perfectly. However when I traverse from the child to the parent I get the wrong parent because I can't filter it to get the correct parent.


So I am wondering if anyone is aware of a patch that I can apply that will allow me to filter the many-to-one relationship.

TIA,
David

PS I have come up with an ugly hack by defining the child class as a many-to-many relationship with the parent (which allows me to apply the filter), however it ends up doing far more database work than necessary when I use it in complex queries.

I have spent the past few days reading through the Hibernate source code trying to create a patch to do something along the lines of my previous post.

However I am confused about how the variable “enabledFilters” is used.

The hibernate code seems to be organized into two phases (a load/setup phase) where the configuration is loaded (and the queries are prepared) and an execution phase (after a session has been established) where objects are actually fetched, cached and so on.

What is confusing me is that the enabledFilters variable seems to be being passed around in the load phase even though it is derived from the session.

Does this mean that when using a filter the load phase is actually executed twice?
- Once when the configuration is initially loaded (with an empty filter map).
- Once after I have set the filter and am executing a query.


TIA,
David

PS Is there any documentation detailing exactly how filters are currently implemented that would also be most helpful.

FWIW, such a patch woud never be accepted into the Hibernate codebase. That is not the intent of filters; they do not effect the multiplicity of associations.

I have no idea what "load phase" vs. "setup phase" is supposed to mean. Obviously a query cannot be prepared outside the scope of a session for many reasons (connections are associated with sessions; enabled filters are associated with sessions; etc).

You need to understand that Hibernate tries to pre-determine as much as possible at session-factory startup time for runtime performance reasons; it then caches these pre-determined things and reuses them whenever possible. Loading stuff in Hibernate is handled by loaders; loaders are one of those things Hibernate attempts to pre-determine. Obviously any enabled filters affect whether or not these cached loaders can be used (as it would mean different SQL). If not, Hibernate generates a loader specific to the current combination of enabled filters.

Loaders and persisters are not bound to any given session, as both are really scoped to the session factory. Thus, the enabled filters need to be passed into these things.

My apologies for using the word query, after reading your post I realized that it wasn’t the best choice of wording. What I was really trying to indicate was the part of the where clause that is pre-determined.

Your reply was also very helpful in clarifying the current architecture; your point about changing the multiplicity of associations is sound (and enabling and disabling filters would have that result).

After reading through the code it seems that discriminators, filters and where attributes all do something close to what I want: adding an extra clauses to the SQL where statement.
In fact another possible approach might be to change the where attribute so that it is parameterized (based on a parameter associated with the session) I think it would do exactly what I need, however I am unsure if there is any way to address the multiplicity issue (does simply having the where “Always on” resolve it)?

If so, is this approach more in line with where the Hibernate team wants the product to go, hence is there any chance such a patch would be accepted?

If not is there anywhere else in the current architecture where such a concept would fit?

Thanks again,
David