[hibernate-dev] Hibernate Filters and EntityManager.find

[Jason Clawson]

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?
>
> Thanks,
>
> 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
> 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?
> >>
> >> 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
>