Open KrzysFR opened 1 year ago
The current state is that tenants are via the db.GetTenant(...) method that returns a (long lived) IFdbTenant
instance, which acts the same way as an IFdbDatabase
instance (implements IFdbRetryable
). Tenant names are wrapper in an FdbTenantName
helper struct which handles most of the way one could want to represent names (tuples, binary literals, ...) and adds a nicer ToString() for debugging purpose.
So typical usage would be:
async Task DoSomething(IFdbDatabase db, FdbTenantName tenant, ...., CancellationToken ct)
{
var res = await db.GetTenant(tenant).ReadWriteAsync(tr => ....., ct);
....
}
The transaction will be attached to the tenant, and be "chroot-ed" inside this tenant keyspace prefix.
To manage tenants (add, delete, list) there are a set of methods on the static class Fdb.Tenants
, for example Fdb.Tenants.CreateTenant(....)
or Fdb.Tenants.DeleteTenant(...)
.
Tenant metadata are exposed via the Fdb.Tenants.GetTenantMetadata(....)
that returns an instance of FdbTenantMetdata
that contains the uniquely assigned Id as well as the binary prefix of this tenant (from the global keyspace).
We need to add support for Tenants (https://apple.github.io/foundationdb/tenants.html) and the associated
FDBTenant
API (https://apple.github.io/foundationdb/api-c.html#c.FDBTenant)If I understand correctly, it is an abstraction that is inserted between the Database and the Transaction:
hello
without interference${A_PREFIX}hello
and${B_PREFIX}hello
.tenant_mode
).Transaction created from the IFdbDatabase act as usual, but transactions created from the IFdbTenant are working on a completely isolated key space, that is the logical equivalent of a Directory Partition: each "tenant" is associated with a unique key prefix that is added to the key, before being stored in the global keyspace.
This looks very similar to what we currently do when "pinning" the FDBDatabase object to a specific partition, except that with tenant, the common key prefix is removed from the view of the application, while with partitions it is still visible.
API
We should add the
IFdbTenant
interface to represent a specific Tenant. Instances of this type could be obtained through theIFdbDatabase
instance (with forwarders on theIFdbDatabaseProvider
for easy access).TODO: investigate the lifetime of instances of
FDBTenant*
If the FDBTenant handle are long-lived, it would be a good idea to cache them, so that obtaining the instance for a specific name, from inside an http request handler would be cheap (same as IFdbDatabaseProvider where the ValueTask is async on the first call, and cached for subsequent calls).
If the FDBTenant handle does not detect that the prefix has changed, maybe we could use deferred value checks for still allow caching of these? (using the
IFdbLayer
convention).