[hibernate-dev] Hibernate Filters and EntityManager.find
jclawson at qualys.com
Thu Dec 1 18:30:37 EST 2011
I found the bug for the multitenency you described in 4.x:
https://hibernate.onjira.com/browse/HHH-6054. There is a comment on there
from Damien Hollis which describes one of the scenarios we face and have
solved with filters + persistence listeners. (I would like to note that
our solution is automatic based on an object type inheritance -> filter
binding... where a filter in our world encompasses a hibernate filter, and
a PrePersist and PostLoad listener)
I think the view you have on what constitutes a multitenent environment is
too narrow. There are a great deal more situations to support and I think
many other companies face these issues as we and Damien are. Damien's
situation can be solved by what we are doing with filters / persistence
listeners. It can be solved better, and more completely, if filters were
active on em.find calls.
On Wed, Nov 30, 2011 at 8:26 AM, Jason Clawson <jclawson at qualys.com> wrote:
> Thanks for your response. Yes it is multi-tenency however that's just
> 1 filter of the 8 we have. We use it for more than just that. For
> example, within a single customer, there are object visibility
> permissions based on a complex interaction between roles and a tree
> with inheritance. Whether or not a user can see a particular object
> is determined by a recursive tree traversing oracle CONNECT BY clause.
> These different visibility filters we have are only applied to
> specific entities. Filters are the right mechanism to handle this as
> they contain all the necessary semantics.... We can disable them for
> certain requests if the current user is an admin, or we can even do it
> for a few specific queries with our sudo concept. They can be applied
> to specific entities and multiple filters can be applied to the same
> entity. And since a relatively recent release they affect DML
> operations (I had to patch hibernate to do this a while ago).
> The multitenency in 4.0 won't work for us. We have a single schema
> based multi tenency. The discrimination based one probably won't work
> either because we need to be able to write a custom SQL clause like we
> can in filters. It would work for customer data separation probably,
> but our other 7 filters can not be modeled in that way since they rely
> on some complex SQL clauses.
> I understand filters work as intended. Can you explain a little about
> why it was intended to ignore the active filters when doing a find?
> And why respecting the filters on a find is bad?
> Jason Clawson
> Sent from my iPhone
> On Nov 30, 2011, at 7:30 AM, Steve Ebersole <steve at hibernate.org> wrote:
> > What you are doing is called multi-tenancy.
> > Hibernate 4 has more explicit support for multi-tenant data.
> Unfortunately 4.0 only supports cases where the schema is replicated on
> multiple databases/schemas. There will also be support for
> discrimination-based multi-tenancy at some point in 4.x (4.1 or 4.2). If
> you want to help develop that feature, that would be great.
> > However, I am not going to change the way/places that filters are
> applied. They work exactly as intended.
> > On Tue 29 Nov 2011 11:24:19 AM CST, Jason Clawson wrote:
> >> Hi everyone. I know that Hibernate session filters do not apply to
> >> find/load operations because the assumption was made that if you know
> >> ID of the entity you wish to load, why tack on the extra WHERE
> >> Please let me explain my use case for filters and illustrate why this
> >> assumption is incorrect.
> >> We use filters to do data separation. For example, separating one
> >> customers data from another's. We also have other filters that do finer
> >> grained object visibility conditions. But lets take a look at customer
> >> data separation since its the easiest to understand. The advantage of
> >> doing customer data separation in this way is that developers don't
> need to
> >> think about it. It just works, and it works *automatically*. The
> >> comes in when you want to do something like em.find(User.class, 1). No
> >> WHERE clause is attached to the SQL statement. Yes, I know the ID, but
> >> really want to tack on to the WHERE clause "AND customerId = 3" to make
> >> sure that someone isn't fuzzing the ID parameter to try and get at
> >> customer's data.
> >> The workaround we have is another mechanism that validates the entity
> in a
> >> PostLoad entity listener and throws an exception if the customerId !=
> >> request's customerId. This is "ok" for the simple example I laid out
> >> However, we now have many more filters that implement complex
> >> rules based on subselects and oracle CONNECT BY clauses which cannot be
> >> implemented using a simple equality check in java. The best, most
> >> performant, solution is to be able to apply the filter clause to the
> >> EntityManager.find operation.
> >> What is your take on this?
> >> Thanks,
> >> Jason Clawson
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > --
> > steve at hibernate.org
> > http://hibernate.org
More information about the hibernate-dev