There is something that is escaping me.
In your view, you would have one ConnectionProvider implementation per
underlying multi-tenant strategy + connection lookup strategy?
ie
JNDIDatasourceConnectionProvider (no multi tenancy support)
SchemaJNDIDatasourceConnectionProvider (multi tenancy wit
Maybe i am just missing the point of your specific passed values.
As currently implemented we really expect a custom ConnectionProvider to deal
with the tenant identifier. I really only see JNDI-based
DataSourceConnectionProvider as something for which we might reasonable supply
a implementat
The reason I initially pushed the difference is because one could imagine some
kind of map between the tenantId passed tot he session and the schema name that
end up being used. But that might be a bit over engineered and the tenant id +
tenantType (tenantStrategy is probably better) is enough i
The connection provider is different yes. The information needed is the same.
For VPD you issues an ALTER SESSION command on the connection to tell it the
"tenant"
On Tuesday, March 29, 2011, at 11:22 am, Emmanuel Bernard wrote:
> Yes but on top of Oracle, I could use the VPD approach or the mo
Yes but on top of Oracle, I could use the VPD approach or the more portable but
less integrated schema approach, right? Somehow the user will be able to chose
and the connection provider will do different magic tricks. Or am I missing
some step?
On 29 mars 2011, at 17:43, Steve Ebersole wrote:
VPD is really the same notion as a tenant. So the ConnectionProvider having
access to the tenant already solves that
On Tuesday, March 29, 2011, at 10:31 am, Emmanuel Bernard wrote:
> For info, I like #2 the best
>
> ConnectionOptions can deal in the future with:
> - schema based diff
> - use
For info, I like #2 the best
ConnectionOptions can deal in the future with:
- schema based diff
- user based diff ala Oracle VPD
interface ConnectionOptions {
TenantType getTenantType();
String getDefaultSchema();
String getUser() //is that how VPD filters out?
..some more technique
Here is the other issue with "separate hierarchies"...
Code that deals with connections now becomes more complicated, having to first
see if there is a SpecializedConnectionProvider and if so grab a connection
from it, otherwise check the ConnectionProvider.
Obviously there are techniques to wo
Well I think I am leaning towards a "parameter object" no matter what we do
otherwise. So call this param object interface ConnectionOptions. It would
have a single method today (err, tomorrow when I write all this :) to get the
tenant id.
The tenant id is really associated with the session.
But 3 is how it's done today since we don't have the other solutions.
So yeah it's magical, but people do manage to make it work. I will
concede that it is not always perceived as straightforward, however.
Something to think about in the grander scheme of things is how someone
would deal with
I think for a user the best option (easiest to understand) would be 1).
3) is too magical. 2) is putting everything in one sack.
Adam
On Mar 22, 2011, at 10:21 PM, Steve Ebersole wrote:
> reference http://opensource.atlassian.com/projects/hibernate/browse/HHH-5697
>
> For multi-tenancy impleme
reference http://opensource.atlassian.com/projects/hibernate/browse/HHH-5697
For multi-tenancy implemented by sepaerate schema we need the ability to tell
the ConnectionProvider about the tenant for the given getConnection() request.
I really see 3 approaches to this:
1) Have 2 hierarchies her
12 matches
Mail list logo
