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

[Steve Ebersole (JIRA)]

    [ https://hibernate.onjira.com/browse/HHH-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46677#comment-46677 ] 

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