Project

General

Profile

Bug #11529

Incorrect Data Structure for TenantManager

Added by Ovidiu Maxiniuc about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:
Multi Tenant

History

#1 Updated by Ovidiu Maxiniuc about 1 month ago

This is an issue I am thinking for some time now. It is not critical, but only because the single client using a MT-enable database accesses a single 4GL logical database.

Currently, the TenantManager has some data structures and exposed APIs so that the tenants are visible across all databases:
   /** Map for retrieving a tenant based on its name. */
   private static final Map<String, Tenant> tenants = new HashMap<>();

   /** Map for retrieving a tenant based on its id. */
   private static final Map<Integer, Tenant> tenantsById = new HashMap<>();

   /** Get a list with all the tenants. [...] */
   public static ArrayList<Tenant> listTenants(List<String> errorSink);

   /** Insert a tenant into the master table. [...]    */
   public static boolean addTenant(String tenantName, String tenantDescription, String tenantInfo, List<TenantDatabaseDescriptor> databases, List<String> errorSink);
This is NOT correct. The tenants are defined as part of a (logical) database. So the structure must be hierarchical like:
Logical Database MT Enabled? Tenant List
db1 Yes Default, db1-t1, db1-t2, db1-t3
db2 No Default
db3 Yes Default, db3-t1, db3-t2
db4 Yes Default, db1-t1, db3-t2

Note that, even if db1 and db4 both have a tenant named db1-t1, they are different entities. Most likely, they will also have different tenant-id, or the tenant-id of a tenant from one logical database may collide with the tenant-id of another, differently named tenant of another logical database. Note that even the Default tenants are actually different instances and they only collide by the name.

Somehow we end up with the structure reversed. The relation between the tenants and logical databases should be many(tenants)-to-one(database) not one-to-many as the current structure and schema of landlord implies. Currently, we do not have application which access multiple databases in MT mode, so this issue is not observable.

In 4GL, each logical database will store the list of tenants (and the associated domains) in the _Tenant and _sec_authentication_domain. In FWD, _sec_authentication_domain is correctly kept in the shared database, but the content of _Tenant are collected together and stored externally, in landlord database.

Also available in: Atom PDF