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 <jclaw...@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 <st...@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@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > -- > > st...@hibernate.org > > http://hibernate.org > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
