doc new feature Steve just added

This commit is contained in:
Gavin 2023-05-19 09:11:40 +02:00
parent eafe6fd79b
commit f0a17e98b9
1 changed files with 15 additions and 2 deletions

View File

@ -126,12 +126,20 @@ var session =
.openSession();
----
However, since we often don't have this level of control of creation of the session, it's more common to supply an implementation of `CurrentTenantIdentifierResolver` to Hibernate.
Or, when using JPA-standard APIs:
[source,java]
----
var entityManager =
entityManagerFactory.createEntityManager(Map.of(HibernateHints.HINT_TENANT_ID, tenantId));
----
However, since we often don't have this level of control over creation of the session, it's more common to supply an implementation of `CurrentTenantIdentifierResolver` to Hibernate.
There are three common ways to implement multi-tenancy:
1. each tenant has its own database,
2. each tenant has its own schema,
2. each tenant has its own schema, or
3. tenants share tables in a single schema, and rows are tagged with the tenant id.
From the point of view of Hibernate, there's little difference between the first two options.
@ -156,6 +164,7 @@ In this case we don't need a `MultiTenantConnectionProvider`, but we will need a
class Account {
@Id String id;
@TenantId String tenantId;
...
}
----
@ -177,6 +186,10 @@ Native SQL queries are _not_ automatically filtered by tenant id; you'll have to
| `hibernate.multi_tenant_connection_provider` | Specifies the `MultiTenantConnectionProvider`
|===
[TIP]
====
If you only need to filter rows by a static condition with no parameters, `@SQLRestriction` is a much simpler way to do that.
====
[[custom-sql]]
=== Using custom-written SQL