| Digging in further, I see 3 main things that are needed:
- The annotation mechanisms - processing those and changing the model accordingly;
- The adjustments to the bits (AST) that will construct the SQL
- A means of injecting the discriminator value - a way for the consumer to indicate the tenant value in the current context.
I'm still noodling about the last one. Here are some possible approaches:
- Piggy-back on the current MultiTenantConnectionProvider. We'd want to genericize that interface (or rather create a genericized parent) since unlike with actual connections the discriminator here may not be a String.
- Add something to the session.... not sure where
- Designate an official name for an (internally managed) filter and use that filter for the implementation and the means letting consumers set the filter params.
Problems with each of those: The first the problem comes down to the fact that when all is done we just have the Connection returned by the connection provider and that interface is not up to Hibernate. So we'd have to look at something wonky like insisting on our own wrapper for those connections and... I just don't see it. Touches too many things. The second approach at first seemed like the obvious but now I'm not sure. Could we designate a specially named property for the EntityManager ? (Hackish for sure.) The third (also hackish) is to have a specially named filter that is added to the Session and available for use. This makes some sense as the obvious implementation for the column-based multi-tenancy is to essentially emulate a Filter for some functions. Regardless of approach taken, the requirement is that a value be passed down from the caller and used in any context where tenancy is being supported. For cases of update and delete operations this is not so much an issue. For insert/create it would be nice if the column value were set from this value provided via context (with mechanism TBD) - though it could also be explicitly set on object creation. That leaves the last part which is querying. For those we'd like to have this (implicit) context change the queries so that only items visible to the tenant are returned. |