[hibernate-dev] Hibernate Filters and EntityManager.find
jclawson at qualys.com
Wed Nov 30 10:26:05 EST 2011
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?
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 the
>> ID of the entity you wish to load, why tack on the extra WHERE condition.
>> 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 problem
>> 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 I
>> 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 another
>> 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 != the
>> request's customerId. This is "ok" for the simple example I laid out here.
>> However, we now have many more filters that implement complex visibility
>> 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?
>> Jason Clawson
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
> steve at hibernate.org
More information about the hibernate-dev