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
+1
On 29 mars 2011, at 18:53, Tom Waterhouse wrote:
> Emmanuel,
>
> The unit test in question is functional, in that it extends SearchTestCase.
> The test requires verification that searchFactoryImplementor.getWorker() is
> never called by FullTextIndexEventListener. Mockito is used in the c
Emmanuel,
The unit test in question is functional, in that it extends SearchTestCase.
The test requires verification that searchFactoryImplementor.getWorker() is
never called by FullTextIndexEventListener. Mockito is used in the current
test
1) to mock both SearchFactoryImplementor and Worker, a
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:
HEM uses them. As @Entity are EJBs, they do need to do some authorization
checks.That's unfortunately more a legacy from EJB 2 than anything else.
On 18 mars 2011, at 20:08, Steve Ebersole wrote:
> Is anyone using or aware of uses of the JACC stuff in org.hibernate.secure?
> I'd like to remove
Hi Tom,
Most tests in HSearch are more integration / functional tests than true unit
tests. Since we can tests everything with in-memory components it ends up quite
fast and more "real life".
If you feel that there is no way to reproduce the issue at hand in a functional
test, is that:
- beca
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
11 matches
Mail list logo
