[
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.
--
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