Follow up on HHH-5697 Closed to add support for discriminator based set ups.
- 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.