Opting out of multitenancy

[gdoenlen]

Hi Rob, I was wondering if you had any advice on opting out of multitenancy for specific queries. I have a decent amount of use cases for cross tenant queries or just objects that are not tenanted. It seems like it would be beneficial to be able to have something like: .usingTenancy(false) on a query to opt out of automatically applying tenancy where clauses.

I've gotten around this currently by using 2 Database objects, one with tenancy enabled and one with it off, both using the same data source, but its much more complex than just being able to opt out for a query.

Additionally, it might be a bug, but even for objects without @TenantId on them my current tenant provider is still being called.

[rbygrave]

I have a decent amount of use cases for (A) cross tenant queries or (B) just objects that are not tenanted.

We pretty much have to limit this discussion to TenantMode.PARTITIONonly as the other tenant options (DB, Schema Catalog etc) don't really lend themselves to a specific query opting out.

For (B) just objects that are not tenanted. ... with TenantMode.PARTITION these are already cross tenant (there is no tenant column on those entities etc) - so perhaps I misunderstand what you mean here but (B) is a non-issue.

That should leave us with (A) a query that would normally execute with TenantMode.PARTITION and add a predicate to the query limiting the result to the current tenant. So here a query.usingTenancy(false) would:

• Stop that predicate being added to the query
• Propagate to any lazy loading / secondary queries and bulk update & delete queries

That is what we mean here or did I misunderstand something?

[certara-gdoenlen]

We pretty much have to limit this discussion to TenantMode.PARTITIONonly as the other tenant options (DB, Schema Catalog etc) don't really lend themselves to a specific query opting out.

Yes I am using partition.

For (B) just objects that are not tenanted. ... with TenantMode.PARTITION these are already cross tenant (there is no tenant column on those entities etc) - so perhaps I misunderstand what you mean here but (B) is a non-issue.

What I saw was that my current tenant provider was still being called even though the object didn't have a @TenantId. I don't think it was being applied to the query, I'll see if I can make a reproduction case.

That should leave us with (A) a query that would normally execute with TenantMode.PARTITION and add a predicate to the query limiting the result to the current tenant. So here a query.usingTenancy(false) would:

Stop that predicate being added to the query
Propagate to any lazy loading / secondary queries and bulk update & delete queries

That is what we mean here or did I misunderstand something?

Yes. This would be helpful for things like background tasks or cross tenant queries without having to do a bunch of threadlocal swaps for the current tenant (and therefore having to do multiple queries). Like I said I've worked around this by just using a second Database instance without the tenancy mode configured, but it still is a bit more complex to setup code wise.

[rbygrave]

Thanks. Yes that all makes sense.

I think we can look at at the "TenantMode.PARTITION + query.usingTenancy(false)" to be:

• Stop that tenant predicate being added to the query
• Propagate to any lazy loading / secondary queries and bulk update & delete queries (no tenant mode)

current tenant provider was still being called even though the object didn't have a @TenantId

Without looking, my suspicion is that it's probably getting the current tenantId for obtaining a connection (even though it isn't actually used there per se - that the datasource is tenant agnostic).

Is there a negative side effect of this? It isn't clear to me why we particularly care about the extra call to obtain the current tenant.

[gdoenlen]

Is there a negative side effect of this? It isn't clear to me why we particularly care about the extra call to obtain the current tenant.

There probably isn't a negative effect and is likely just a me problem (or a my company problem) and not understanding how your tenancy implementation works. For some history, at work we've been using Ebean for a long time and had implemented our own tenancy implementation using interfaces and a BeanPersistAdapter to set the tenant field on a bean pre-save or to add .eq(TENANT, currentTenant) on queries. In these cases I've thrown exceptions if there is no tenant and that is how I have my current tenant provider currently setup:

var tenant = getFromThreadLocal();
if (tenant == null) {
   throw new IllegalStateException("need a tenant but none is set");
}

The idea is to essentially fail fast if a query happens on a bean that is supposed to be tenanted but there is none to apply for the where clauses. So with my implementation it ends up crashing when there is no tenant and it's called. I'm assuming there is probably similar logic in your implementation where if a bean with @TenantId is queried and the tenant is null?