[hibernate-issues] [Hibernate-JIRA] Updated: (HHH-6054) Support for discriminator-based multi-tenancy
Steve Ebersole (JIRA)
noreply at atlassian.com
Tue Dec 27 13:06:25 EST 2011
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
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
More information about the hibernate-issues
mailing list