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 implementation.
To be honest the ConnectionProvider is not the difficult part to this. The
isolation within the Session and second level cache are by far the more useful
things.
Of course I am open to suggestions here if anyone thinks we should provide
support for concrete, tenant-aware ConnectionProviders out-of-the-box *and*
has an idea what that looks like and how to actually do it in a clean way.
On Tuesday, March 29, 2011, at 12:36 pm, Emmanuel Bernard wrote:
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
info.
Emmanuel
On 29 mars 2011, at 18:30, Steve Ebersole wrote:
> 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 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
>>>> - user based diff ala Oracle VPD
>>>>
>>>> interface ConnectionOptions {
>>>>
>>>> TenantType getTenantType();
>>>> String getDefaultSchema();
>>>> String getUser() //is that how VPD filters out?
>>>> ..some more techniques later
>>>>
>>>> }
>>>>
>>>> enum TenantType {
>>>>
>>>> NONE,
>>>> SCHEMA,
>>>> USER
>>>>
>>>> }
>>>>
>>>> With getTenantType, a ConnectionProvider can return the right
>>>> connection or yell if it does not support it. We could also imagine
>>>> asking the ConnectionProvider to return the array of supported
>>>> tenantTypes so that we can raise the exception at startup time.
>>>>
>>>> On 22 mars 2011, at 22:21, Steve Ebersole wrote:
>>>>> 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 here. The current ConnectionProvider
contract
>>>>> remains the same. Add a new MultiTenantConnectionProvider with
>>>>> methods accounting for tenant
>>>>> 2) Just alter the ConnectionProvider contract to pass information
in.
>>>>> If we go this route I prefer the "parameter object"
pattern where we
>>>>> pass in ConnectionOptions interface (see issue).
>>>>> 3) Use contextual lookup. ConnentionProviders interested in (or
>>>>> capable of understanding) mulit-tenancy would perform some kind of
>>>>> "contextual" (ThreadLocal, etc) lookup for the needed
information.
>>>>>
>>>>> Thoughts? Discussions?
>>>>>
>>>>> ---
>>>>> Steve Ebersole <steve(a)hibernate.org>
>>>>>
http://hibernate.org
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>> ---
>>> Steve Ebersole <steve(a)hibernate.org>
>>>
http://hibernate.org
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ---
> Steve Ebersole <steve(a)hibernate.org>
>
http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev