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 <st...@hibernate.org>
> >>>>> http://hibernate.org
> >>>>> _______________________________________________
> >>>>> hibernate-dev mailing list
> >>>>> hibernate-dev@lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>> ---
> >>> Steve Ebersole <st...@hibernate.org>
> >>> http://hibernate.org
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev@lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > ---
> > Steve Ebersole <st...@hibernate.org>
> > http://hibernate.org
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
---
Steve Ebersole <st...@hibernate.org>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
