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

[Steve Ebersole (JIRA)]

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

-- 
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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira