[
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