I am in currently in the process of writing the Tokio/Rust bindings for the Tenant API.
As I was studying the API, it looks like it is possible to transactionally create and delete multiple tenants using createTenant and deleteTenant methods on TentantManagement class that takes a transaction as an argument.
After tenants have been created, is there a way to transactionally mutate data in multiple tenants? I noticed the presence of RAW_ACCESS option. When using this option, how would I know the subspace of the tentants? Can it be read from somewhere?
Also would the system key \xff/metadataVersion be accessible from tenant mode? Basically if we have something like RecordMetaData in one tenant (and cached in the client) and RecordStore in another tenant, can we use \xff/metadataVersion to detect changes to the meta data?
Creating and deleting tenants supports multiple tenants in one transaction.
In the current state tenants on the same cluster will all share the same \xff/metadataVersion. This may change in the future so that each tenant gets its own key though.
My understanding is that tenants are intended to be isolated transaction domains, and so transactionally mutating data in multiple tenants is not a use-case that is or will be considered in the design of this feature. If you have data that you want to transact across, the intent is that you organize it into a single tenant. Future features may make it impossible to transact across two tenants.
As you noted, it may be possible to use the RAW_ACCESS transaction option to accomplish this, but you’re going to be a bit “on your own” if you take that approach. If you want to find the prefix for a tenant you can read it from special keys: Tenants — FoundationDB 7.1 (\xff\xff/management/tenant_map/<tenant_name>)
Also just want to remind you that this feature is still considered experimental.
@alloc@jzhou I was wondering if there have been discussions on potential changes to RecordLayer in order to use FDB Tenant APIs? For our use-case, we might not directly use the RecordLayer, but we would like to learn as much as possible from its design.
Based on my limited understanding of the RecordLayer, and reading this comment on HN, it seems to me that one of key aspects of RL design is to store a value of prototobuf message type RecordMetaData.Metadata as “Metadata Store”.
It also looks to me that the RecordLayer tenancy model assumes that the values of RecordMetaData.Metadata would be cached in the client, and per-tenant Record Store would be read and mutated using protobuf dynamic message feature.
Would you please be able to comment on how the RL tenancy model might change when using FDB Tentant API?
How would the presence of per-tenant \xff/metadataVersion in future impact meta-data change detection?