> 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. > There is also a case to be made to not allow different tenants to see each > other data. Obviously ;) > so unless we can catch all malicious SQL queries, it's better disabled by > default. > though I could see an app developer knowing his environment and enabling the > option if needed. I guess the question is more about whether people had ideas for "catch(ing) [and properly morphing] all malicious SQL queries". In my opinion, thats a pretty tall task. Essentially we would need database-specific SQL parsers -- st...@hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
