. 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(a)qualys.com> wrote:
Thanks for your response. Yes it is multi-tenency however that's
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(a)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
>> 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
>> 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
>> PostLoad entity listener and throws an exception if the customerId !=
>> request's customerId. This is "ok" for the simple example I laid
>> 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?
>> Jason Clawson
>> hibernate-dev mailing list