On Wed 04 Apr 2012 04:26:30 PM CDT, Steve Ebersole wrote: >> I am not sure how the PaaS multi-tenant config will look like exactly >> but if we can >> automatically prefix the 2LC regions without adding an explicit >> mandatory property >> that would be nice. > > Sure. The problem is that in the JPA-supported PaaS model, there is > only really a need to know the tenant identifier when using > SHARED_TABLE approach. There is a part of the proposal about making > the tenant identifier available via ENC/JNDI. However, given that only > the SHARED_TABLE approach (what we call DISCRIMINATED btw) in JPA > needs access to it, I was not clear if that would be available to all > approaches. But even there, I am not sure the ENC entry would be > available when the EMF is getting built. This ties into THE critical > difference between the multi-tenancy support I did already and what > JPA is proposing: namely, Hibernate multi-tenancy supports a single > SF/EMF instance serving multiple tenants, whereas the JPA model would > constrain one EMF to serve a single tenant. > > So short answer.. I don't know either. But if it the tenant identifier > is know when building EMF/SF, then yes, the plan was to use region > prefixes.
Just clarified that: a) the tenant identifier would be made available regardless of the multi-tenancy approach, b) the tenant identifier would be made available when the EMF/SF is starting up; not via JNDI though, the container is expected to pass it along to the JPA provider via createEMF call. So it looks like there will in fact be an explicit config setting for this. Additionally, we are probably going to need another new setting to indicate whether to enable single-EMF-serves-one-tenant versus single-EMF-serves-multiple-tenants support (good name suggestions for this?). Also, it looks like JPA will not standardize an annotation for naming the tenant identifier column in mappings for the SHARED_TABLE (DISCRIMINATED) approach. So we need to decide if we are going to supply our own annotation or fall in line with the JPA assumption that the column would just be named the same for all shared tables. Still one more consideration is whether (and if so, how) we want to allow for mixed multi-tenant and non-multi-tenant data. Imagine a trivial example of a COUNTRY code-set table, where all tenants are sharing that data. This is really just a concern with SHARED_TABLE multi-tenancy, although even in the other 2 approaches it would be nice to know that as we could limit second-level caching footprint for that shared data. Basically I see opt-in and opt-out as the 2 options here. Personally I prefer that if multi-tenancy is enabled that we assume all data is multi-tenant and any shared data would need to be opted-out. I can see 2 opting-mechanisms: a) mapping data (annotation) b) config property (hibernate.multi_tenancy.shared_entities Any other suggestions/thoughts? -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
