FWD » Core Development » Runtime Infrastructure

At this moment, (almost) the all the information for supporting tenants is stored and managed in an external database generically named 'landlord'. The flow is that, using the specific REST API the tenants are created/modified/deleted in this database and at the server startup the information is copied in the true _Tenant table from meta database. With the current implementation, to benefit form the changes in this database, the server had to be restarted. With #8976, the changes in landlord related to this table will be automatically replicated to the meta table so it will be in sync. However, in my tests I noticed that the users (at least the default tenant) are able to do their own changes into the _Tenant meta-table. These changes will NOT reach the landlord database so they are lost when the FWD server is restarted and are invisible to the admin, since the implementation of the REST API will only look at the landlord database.

So, my idea is to drop the initialization, replication and synchronization processes, and instead write (and read) the tenant data from the _Tenant table. For that, the _Tenant table must be converted to a persistent table, therefore 'moved' from meta schema to each persistent database, the very same way we do with _User and _sec-authentication* tables at this moment. As noted above, the data would be stored in a single place and no synchronization in any direction will be necessary, both the admins (accessing from REST) and the the clients (with normal database sessions/contexts) will have the same image of the _Tenant table.

Unfortunately, the 'landlord' database is still necessary. It will store only information we cannot store (both because there are no specific fields/columns, and security since the users MUST not access it) in _Tenant tables. That is the connection URL, the user and the password for private tenant databases. There is also another solution, to move these pieces of information in a hidden table (no 4GL interface hence inaccessible to 4GL users) in the default database of each logical database.

Greg,

In my opinion this is a better solution than that we have now implemented. Of course it might not be perfect since we still need to store data in two separate databases. A solution variant would store the URL/user/pwd for tenant also in _Tenant table, as hidden columns from 4GL, but only accessible from admin REST API. This would allow us to drop landlord database completely, but the DDLs for that table need to be augmented at some phase.

As I am adding code for other features, this gets burrowed and it will be more difficult later to address the issues I emphasized in first note.
For this, I would like to have your input on this matter rather sooner than later.

Thank you!

We have a general rule that administrative features of OE are not implemented. FWD is designed to implement the user-accessible features of the 4GL language. The idea is that admin features are not something that are normally exposed to users, so they can be safely excluded.

Why do we do this?

• There can be quite a lot of functionality to implement for admin features but the amount of 4GL code written for that is very small. In fact, most of these admin facilities have no counterpart in the 4GL language itself.
• Admin features tend to be low level. This means they are closer to the implementation details of the corresponding parts of the system, so they are much more likely to be very different in PostgreSQL, MariaDB, the JVM... than in OE. This means that mapping them to something compatible is a bigger job.
• The admin features typically affect devops people, DBAs and system administrators not real users. All of these admin people are IT professionals and can be reasonably expected to learn new processes.

For these reasons is not a high value thing to implement compatiblity for admin features. Then we add this very important point: the OE admin features are generally not very capable. When they exist at all, they are often rudimentary and far behind what already exists in modern platforms like PostgreSQL, MariaDB, the JVM. Using the "native" admin facilities is a big improvement over something that would be OE compatible.

I explain all of this to set some context for why we may decide to do things differently for this case.

We explicitly tell customers that in regard to the multi-tenant support, we do not support the OE multi-tenant admin features which are largely implemented as built-in OO classes. This means that any 4GL code written to administer tenants must be rewritten. We don't now and would NOT want to support administrative changes to the tenants via direct editing of the _tenant metadata using 4GL code.

We provide a custom REST API for management of the tenant data. Mixing that with direct editing of _tenant is nasty and not a good thing long term.

I don't think the proposed approach is the way we would want to go.