[Hibernate-JIRA] Created: (HHH-6054) Support for discriminator-based multi-tenancy

older

[Hibernate-JIRA] (HBX-1216) Can't...

[Hibernate-JIRA] (HHH-7868)...

Steve Ebersole (JIRA)

Friday, 25 March 2011 Fri, 25 Mar '11

6:47 p.m.

Show replies by date

Steve Ebersole (JIRA)

Saturday, 16 April Sat, 16 Apr

7:57 a.m.

New subject: [Hibernate-JIRA] Updated: (HHH-6054) Support for discriminator-based multi-tenancy

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054?page=c... ] Steve Ebersole updated HHH-6054: -------------------------------- Description: Follow up on HHH-5697 to add support for discriminator based set ups. Considerations: # What is the design of this in the metadata? ## At minimum we need to know the column to use for discrimination. ## Personally believe this should not be a attribute/property based. Should just name a column to use. # We really should discover up front whether a {{SessionFactory}} contains any tenant data and require tenant identifier to be set in these cases. ## Explicit. The user passes us something saying that the {{SessionFactory}} involves multi tenancy ## Implied. Checking the connection provider (based on current split there) can indicate schema-based multi-tenancy. Checking all entities can imply the same for discriminator-based ## May need a way to allow user to tell us which approach to use. That might be the explicit option. # Insert statements need to be altered to include the tenant identifier # All selects need to be altered to add predicate condition based on tenant identifier. ## Allow switch to say whether this is done as a literal versus done as a JDBC parameter. This has been requested couple of times in regards filters as well to deal with database partitions and database query optimizers that need the partition value to be a literal. All persistence context and second level cache related keys are already handled in the first phase. was:Follow up on HHH-5697 to add support for discriminator based set ups

...

Support for discriminator-based multi-tenancy --------------------------------------------- Key: HHH-6054 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054 Project: Hibernate Core Issue Type: Task Components: core Reporter: Steve Ebersole Fix For: 4.0.0.Alpha3 Follow up on HHH-5697 to add support for discriminator based set ups. Considerations: # What is the design of this in the metadata? ## At minimum we need to know the column to use for discrimination. ## Personally believe this should not be a attribute/property based. Should just name a column to use. # We really should discover up front whether a {{SessionFactory}} contains any tenant data and require tenant identifier to be set in these cases. ## Explicit. The user passes us something saying that the {{SessionFactory}} involves multi tenancy ## Implied. Checking the connection provider (based on current split there) can indicate schema-based multi-tenancy. Checking all entities can imply the same for discriminator-based ## May need a way to allow user to tell us which approach to use. That might be the explicit option. # Insert statements need to be altered to include the tenant identifier # All selects need to be altered to add predicate condition based on tenant identifier. ## Allow switch to say whether this is done as a literal versus done as a JDBC parameter. This has been requested couple of times in regards filters as well to deal with database partitions and database query optimizers that need the partition value to be a literal. All persistence context and second level cache related keys are already handled in the first phase.

-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

Steve Ebersole (JIRA)

8 a.m.

New subject: [Hibernate-JIRA] Commented: (HHH-6054) Support for discriminator-based multi-tenancy

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054?page=c... ] Steve Ebersole commented on HHH-6054: ------------------------------------- Really need the new metamodel code to stabilize to start this.

...

Steve Ebersole (JIRA)

3:03 p.m.

New subject: [Hibernate-JIRA] Updated: (HHH-6054) Support for discriminator-based multi-tenancy

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054?page=c... ] Steve Ebersole updated HHH-6054: -------------------------------- Issue Type: New Feature (was: Task)

...

Support for discriminator-based multi-tenancy --------------------------------------------- Key: HHH-6054 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054 Project: Hibernate Core Issue Type: New Feature Components: core Reporter: Steve Ebersole Fix For: 4.0.0.Alpha3 Follow up on HHH-5697 to add support for discriminator based set ups. Considerations: # What is the design of this in the metadata? ## At minimum we need to know the column to use for discrimination. ## Personally believe this should not be a attribute/property based. Should just name a column to use. # We really should discover up front whether a {{SessionFactory}} contains any tenant data and require tenant identifier to be set in these cases. ## Explicit. The user passes us something saying that the {{SessionFactory}} involves multi tenancy ## Implied. Checking the connection provider (based on current split there) can indicate schema-based multi-tenancy. Checking all entities can imply the same for discriminator-based ## May need a way to allow user to tell us which approach to use. That might be the explicit option. # Insert statements need to be altered to include the tenant identifier # All selects need to be altered to add predicate condition based on tenant identifier. ## Allow switch to say whether this is done as a literal versus done as a JDBC parameter. This has been requested couple of times in regards filters as well to deal with database partitions and database query optimizers that need the partition value to be a literal. All persistence context and second level cache related keys are already handled in the first phase.

Steve Ebersole (JIRA)

Tuesday, 3 May Tue, 3 May

3:09 p.m.

New subject: [Hibernate-JIRA] Updated: (HHH-6054) Support for discriminator-based multi-tenancy

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054?page=c... ] Steve Ebersole updated HHH-6054: -------------------------------- Fix Version/s: (was: 4.0.0.Alpha3) 4.0.0.Beta1 Either part of HHH-5661 or dependent upon HHH-5661

...

Support for discriminator-based multi-tenancy --------------------------------------------- Key: HHH-6054 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054 Project: Hibernate Core Issue Type: New Feature Components: core Reporter: Steve Ebersole Fix For: 4.0.0.Beta1 Follow up on HHH-5697 to add support for discriminator based set ups. Considerations: # What is the design of this in the metadata? ## At minimum we need to know the column to use for discrimination. ## Personally believe this should not be a attribute/property based. Should just name a column to use. # We really should discover up front whether a {{SessionFactory}} contains any tenant data and require tenant identifier to be set in these cases. ## Explicit. The user passes us something saying that the {{SessionFactory}} involves multi tenancy ## Implied. Checking the connection provider (based on current split there) can indicate schema-based multi-tenancy. Checking all entities can imply the same for discriminator-based ## May need a way to allow user to tell us which approach to use. That might be the explicit option. # Insert statements need to be altered to include the tenant identifier # All selects need to be altered to add predicate condition based on tenant identifier. ## Allow switch to say whether this is done as a literal versus done as a JDBC parameter. This has been requested couple of times in regards filters as well to deal with database partitions and database query optimizers that need the partition value to be a literal. All persistence context and second level cache related keys are already handled in the first phase.

Damien Hollis (JIRA)

Thursday, 19 May Thu, 19 May

10:29 p.m.

New subject: [Hibernate-JIRA] Commented: (HHH-6054) Support for discriminator-based multi-tenancy

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054?page=c... ] Damien Hollis commented on HHH-6054: ------------------------------------ We specifically use discriminator based multi-tenancy because we have a network of tenants that have relationships with each other and certain data created by one tenant is accessible by another tenant (potentially only in a read-only form). Are you planning on including support for this kind of scenario? In particular, will it be possible to navigate across these types of relationships and perform some queries where the tenant discriminator is disabled?

...

Support for discriminator-based multi-tenancy --------------------------------------------- Key: HHH-6054 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054 Project: Hibernate Core Issue Type: New Feature Components: core Reporter: Steve Ebersole Fix For: 4.0.0.Beta1 Follow up on HHH-5697 to add support for discriminator based set ups. Considerations: # What is the design of this in the metadata? ## At minimum we need to know the column to use for discrimination. ## Personally believe this should not be a attribute/property based. Should just name a column to use. # We really should discover up front whether a {{SessionFactory}} contains any tenant data and require tenant identifier to be set in these cases. ## Explicit. The user passes us something saying that the {{SessionFactory}} involves multi tenancy ## Implied. Checking the connection provider (based on current split there) can indicate schema-based multi-tenancy. Checking all entities can imply the same for discriminator-based ## May need a way to allow user to tell us which approach to use. That might be the explicit option. # Insert statements need to be altered to include the tenant identifier # All selects need to be altered to add predicate condition based on tenant identifier. ## Allow switch to say whether this is done as a literal versus done as a JDBC parameter. This has been requested couple of times in regards filters as well to deal with database partitions and database query optimizers that need the partition value to be a literal. All persistence context and second level cache related keys are already handled in the first phase.

Steve Ebersole (JIRA)

Wednesday, 8 June Wed, 8 Jun

11:22 a.m.

New subject: [Hibernate-JIRA] Updated: (HHH-6054) Support for discriminator-based multi-tenancy

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054?page=c... ] Steve Ebersole updated HHH-6054: -------------------------------- Fix Version/s: (was: 4.0.0.Beta1) 4.1.0

...

Support for discriminator-based multi-tenancy --------------------------------------------- Key: HHH-6054 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054 Project: Hibernate Core Issue Type: New Feature Components: core Reporter: Steve Ebersole Fix For: 4.1.0 Follow up on HHH-5697 to add support for discriminator based set ups. Considerations: # What is the design of this in the metadata? ## At minimum we need to know the column to use for discrimination. ## Personally believe this should not be a attribute/property based. Should just name a column to use. # We really should discover up front whether a {{SessionFactory}} contains any tenant data and require tenant identifier to be set in these cases. ## Explicit. The user passes us something saying that the {{SessionFactory}} involves multi tenancy ## Implied. Checking the connection provider (based on current split there) can indicate schema-based multi-tenancy. Checking all entities can imply the same for discriminator-based ## May need a way to allow user to tell us which approach to use. That might be the explicit option. # Insert statements need to be altered to include the tenant identifier # All selects need to be altered to add predicate condition based on tenant identifier. ## Allow switch to say whether this is done as a literal versus done as a JDBC parameter. This has been requested couple of times in regards filters as well to deal with database partitions and database query optimizers that need the partition value to be a literal. All persistence context and second level cache related keys are already handled in the first phase.

Steve Ebersole (JIRA)

Thursday, 16 June Thu, 16 Jun

4:04 p.m.

New subject: [Hibernate-JIRA] Commented: (HHH-6054) Support for discriminator-based multi-tenancy

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054?page=c... ] Steve Ebersole commented on HHH-6054: ------------------------------------- No, I do not plan support for that.

...

Support for discriminator-based multi-tenancy --------------------------------------------- Key: HHH-6054 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054 Project: Hibernate Core Issue Type: New Feature Components: core Reporter: Steve Ebersole Fix For: 4.1.0 Follow up on HHH-5697 to add support for discriminator based set ups. Considerations: # What is the design of this in the metadata? ## At minimum we need to know the column to use for discrimination. ## Personally believe this should not be a attribute/property based. Should just name a column to use. # We really should discover up front whether a {{SessionFactory}} contains any tenant data and require tenant identifier to be set in these cases. ## Explicit. The user passes us something saying that the {{SessionFactory}} involves multi tenancy ## Implied. Checking the connection provider (based on current split there) can indicate schema-based multi-tenancy. Checking all entities can imply the same for discriminator-based ## May need a way to allow user to tell us which approach to use. That might be the explicit option. # Insert statements need to be altered to include the tenant identifier # All selects need to be altered to add predicate condition based on tenant identifier. ## Allow switch to say whether this is done as a literal versus done as a JDBC parameter. This has been requested couple of times in regards filters as well to deal with database partitions and database query optimizers that need the partition value to be a literal. All persistence context and second level cache related keys are already handled in the first phase.

Jason Clawson (JIRA)

Tuesday, 6 December Tue, 6 Dec

4:27 p.m.

New subject: [Hibernate-JIRA] Commented: (HHH-6054) Support for discriminator-based multi-tenancy

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054?page=c... ] Jason Clawson commented on HHH-6054: ------------------------------------ To Damien's point... We have multitenency support in hibernate implemented using hibernate filters. We are able to model the exact multitenent requirements Damien has described. Some of our user permission discriminated data is based on a recursive oracle CONNECT BY query against a graph. The only problem with our solution is that EntityManager.find(id) bypasses the filter because hibernate filters do not get applied to find() operations. I asked about this on the mailing list and got the reply: "I am not going to change the way/places that filters are applied. They work exactly as intended" and then referred me to version 4.1 that would feature "discriminator-based multi-tenency". The multitency solution described here will not work for me, nor Damien and is too simple of a view on what multi-tenency means. This is what multi-tenency means to me: 1) Separate 1 customer's data from another 2) Allow some users to see 1 or more customer's data. They might be super admins that can see all customers, they might be sales people who can see a subset of customers. They might have a network of hierarchical tenents as Damien described. 3) within a customer, restrict the data that a specific user can see based on their permissions. This permissions query in my world is a complicated recursive query 4) be able to disable filters (allow all data) for a specific set of queries depending on need Our solution using filters solves all of the above cases. We have had to override EntityManager.find to do a query instead of the simple find operation in order to get the filter to activate. Having a domain object protected by the customer filter is as easy as extending the CustomerDomainObject class. Likewise, being protected by the user permissions filter is as easy as extending UserProtectedDomainObject. The filters are additive and bound programmatically at startup.

...

Support for discriminator-based multi-tenancy --------------------------------------------- Key: HHH-6054 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054 Project: Hibernate Core Issue Type: New Feature Components: core Reporter: Steve Ebersole Labels: multi-tenancy Fix For: 4.1.0 Follow up on HHH-5697 to add support for discriminator based set ups. Considerations: # What is the design of this in the metadata? ## At minimum we need to know the column to use for discrimination. ## Personally believe this should not be a attribute/property based. Should just name a column to use. # We really should discover up front whether a {{SessionFactory}} contains any tenant data and require tenant identifier to be set in these cases. ## Explicit. The user passes us something saying that the {{SessionFactory}} involves multi tenancy ## Implied. Checking the connection provider (based on current split there) can indicate schema-based multi-tenancy. Checking all entities can imply the same for discriminator-based ## May need a way to allow user to tell us which approach to use. That might be the explicit option. # Insert statements need to be altered to include the tenant identifier # All selects need to be altered to add predicate condition based on tenant identifier. ## Allow switch to say whether this is done as a literal versus done as a JDBC parameter. This has been requested couple of times in regards filters as well to deal with database partitions and database query optimizers that need the partition value to be a literal. All persistence context and second level cache related keys are already handled in the first phase.

-- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

Steve Ebersole (JIRA)

Tuesday, 27 December Tue, 27 Dec

12:06 p.m.

New subject: [Hibernate-JIRA] Updated: (HHH-6054) Support for discriminator-based multi-tenancy

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054?page=c... ] Steve Ebersole updated HHH-6054: -------------------------------- Fix Version/s: (was: 4.1.0) 5.0.0

...

Support for discriminator-based multi-tenancy --------------------------------------------- Key: HHH-6054 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054 Project: Hibernate Core Issue Type: New Feature Components: core Reporter: Steve Ebersole Labels: multi-tenancy Fix For: 5.0.0 Follow up on HHH-5697 to add support for discriminator based set ups. Considerations: # What is the design of this in the metadata? ## At minimum we need to know the column to use for discrimination. ## Personally believe this should not be a attribute/property based. Should just name a column to use. # We really should discover up front whether a {{SessionFactory}} contains any tenant data and require tenant identifier to be set in these cases. ## Explicit. The user passes us something saying that the {{SessionFactory}} involves multi tenancy ## Implied. Checking the connection provider (based on current split there) can indicate schema-based multi-tenancy. Checking all entities can imply the same for discriminator-based ## May need a way to allow user to tell us which approach to use. That might be the explicit option. # Insert statements need to be altered to include the tenant identifier # All selects need to be altered to add predicate condition based on tenant identifier. ## Allow switch to say whether this is done as a literal versus done as a JDBC parameter. This has been requested couple of times in regards filters as well to deal with database partitions and database query optimizers that need the partition value to be a literal. All persistence context and second level cache related keys are already handled in the first phase.

-- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

Steve Ebersole (JIRA)

Friday, 9 March Fri, 9 Mar

9:07 p.m.

New subject: [Hibernate-JIRA] Updated: (HHH-6054) Support for discriminator-based multi-tenancy

[ https://hibernate.onjira.com/browse/HHH-6054?page=com.atlassian.jira.plug... ] Steve Ebersole updated HHH-6054: -------------------------------- Assignee: Steve Ebersole

...

Support for discriminator-based multi-tenancy --------------------------------------------- Key: HHH-6054 URL: https://hibernate.onjira.com/browse/HHH-6054 Project: Hibernate ORM Issue Type: New Feature Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Labels: multi-tenancy Fix For: 5.0.0 Follow up on HHH-5697 to add support for discriminator based set ups. Considerations: # What is the design of this in the metadata? ## At minimum we need to know the column to use for discrimination. ## Personally believe this should not be a attribute/property based. Should just name a column to use. # We really should discover up front whether a {{SessionFactory}} contains any tenant data and require tenant identifier to be set in these cases. ## Explicit. The user passes us something saying that the {{SessionFactory}} involves multi tenancy ## Implied. Checking the connection provider (based on current split there) can indicate schema-based multi-tenancy. Checking all entities can imply the same for discriminator-based ## May need a way to allow user to tell us which approach to use. That might be the explicit option. # Insert statements need to be altered to include the tenant identifier # All selects need to be altered to add predicate condition based on tenant identifier. ## Allow switch to say whether this is done as a literal versus done as a JDBC parameter. This has been requested couple of times in regards filters as well to deal with database partitions and database query optimizers that need the partition value to be a literal. All persistence context and second level cache related keys are already handled in the first phase.

-- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

Steve Ebersole (JIRA)

Wednesday, 16 May Wed, 16 May

9:56 a.m.

New subject: [Hibernate-JIRA] Commented: (HHH-6054) Support for discriminator-based multi-tenancy

[ https://hibernate.onjira.com/browse/HHH-6054?page=com.atlassian.jira.plug... ] Steve Ebersole commented on HHH-6054: ------------------------------------- @Jason, most of the things on your list specifically are not multi-tenancy, You are simply lumping requirements together.

...

Support for discriminator-based multi-tenancy --------------------------------------------- Key: HHH-6054 URL: https://hibernate.onjira.com/browse/HHH-6054 Project: Hibernate ORM Issue Type: New Feature Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Labels: multi-tenancy Fix For: 5.0.0 Time Spent: 6h 22m Follow up on HHH-5697 to add support for discriminator based set ups. Considerations: # What is the design of this in the metadata? ## At minimum we need to know the column to use for discrimination. ## Personally believe this should not be a attribute/property based. Should just name a column to use. # We really should discover up front whether a {{SessionFactory}} contains any tenant data and require tenant identifier to be set in these cases. ## Explicit. The user passes us something saying that the {{SessionFactory}} involves multi tenancy ## Implied. Checking the connection provider (based on current split there) can indicate schema-based multi-tenancy. Checking all entities can imply the same for discriminator-based ## May need a way to allow user to tell us which approach to use. That might be the explicit option. # Insert statements need to be altered to include the tenant identifier # All selects need to be altered to add predicate condition based on tenant identifier. ## Allow switch to say whether this is done as a literal versus done as a JDBC parameter. This has been requested couple of times in regards filters as well to deal with database partitions and database query optimizers that need the partition value to be a literal. All persistence context and second level cache related keys are already handled in the first phase.

-- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

Steve Ebersole (JIRA)

9:58 a.m.

New subject: [Hibernate-JIRA] Commented: (HHH-6054) Support for discriminator-based multi-tenancy

[ https://hibernate.onjira.com/browse/HHH-6054?page=com.atlassian.jira.plug... ] Steve Ebersole commented on HHH-6054: ------------------------------------- The definition of metadata for this approach is all in place. The Binder binds it into the binding model. Still have to carry that over to the persisters.

...

Support for discriminator-based multi-tenancy --------------------------------------------- Key: HHH-6054 URL: https://hibernate.onjira.com/browse/HHH-6054 Project: Hibernate ORM Issue Type: New Feature Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Labels: multi-tenancy Fix For: 5.0.0 Time Spent: 6h 22m Follow up on HHH-5697 to add support for discriminator based set ups. Considerations: # What is the design of this in the metadata? ## At minimum we need to know the column to use for discrimination. ## Personally believe this should not be a attribute/property based. Should just name a column to use. # We really should discover up front whether a {{SessionFactory}} contains any tenant data and require tenant identifier to be set in these cases. ## Explicit. The user passes us something saying that the {{SessionFactory}} involves multi tenancy ## Implied. Checking the connection provider (based on current split there) can indicate schema-based multi-tenancy. Checking all entities can imply the same for discriminator-based ## May need a way to allow user to tell us which approach to use. That might be the explicit option. # Insert statements need to be altered to include the tenant identifier # All selects need to be altered to add predicate condition based on tenant identifier. ## Allow switch to say whether this is done as a literal versus done as a JDBC parameter. This has been requested couple of times in regards filters as well to deal with database partitions and database query optimizers that need the partition value to be a literal. All persistence context and second level cache related keys are already handled in the first phase.

-- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

Damien Hollis (JIRA)

Wednesday, 18 July Wed, 18 Jul

9 p.m.

New subject: [Hibernate-JIRA] (HHH-6054) Support for discriminator-based multi-tenancy

Steve Ebersole (JIRA)

9:18 p.m.

New subject: [Hibernate-JIRA] (HHH-6054) Support for discriminator-based multi-tenancy

Asif Tasleem (JIRA)

Sunday, 16 December Sun, 16 Dec

12:14 a.m.

New subject: [Hibernate-JIRA] (HHH-6054) Support for discriminator-based multi-tenancy

Asif Tasleem (JIRA)

12:14 a.m.

New subject: [Hibernate-JIRA] (HHH-6054) Support for discriminator-based multi-tenancy

Asif Tasleem (JIRA)

12:50 a.m.

New subject: [Hibernate-JIRA] (HHH-6054) Support for discriminator-based multi-tenancy

4390

days inactive

5022

days old

hibernate-issues@lists.jboss.org

Manage subscription

17 comments

4 participants

tags (0)

participants (4)

Asif Tasleem (JIRA)
Damien Hollis (JIRA)
Jason Clawson (JIRA)
Steve Ebersole (JIRA)

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

[Hibernate-JIRA] Created: (HHH-6054) Support for discriminator-based multi-tenancy