FWD » Core Development » Runtime Infrastructure

• In TenantManager$TenantSQL.CREATE_SYSTEM_TABLE, the column pam_library_checksum is of type BINARY (the equivalent of RAW from 4GL). The keyword BINARY is H2 specific and needs to be modified according to the dialect in use.
• In TenantManager$TenantSQL, both INSERT_DOMAIN and INSERT_DOMAIN_TYPE use MERGE INTO. The original intention was to skip adding a specific record if it already exists, but since H2 doesn't offer a straight-forward approach, I opted for this.
  • For reference, in MariaDB, one can use INSERT IGNORE and in PostgreSQL, one can use INSERT ... ON CONFLICT DO NOTHING.
• When the support for multiple dialects will be implemented, the dialect will need to be extracted from the URL. In order to achieve this, there is a bit of code in DatabaseManager.createSettings that handles this exact thing. This could be used as a reference point.

If other changes appear in the meantime, I'll keep this task up to date.

• This is like the smallest complaint ever, but in MariaDbLenientDialect and in P2JH2Dialect, the return statement of the functions getCreateMasterTable() and getCreateDatabasesTable() is a bit misaligned.
  • How it is currently:
    

                return "CREATE TABLE IF NOT EXISTS master (\n"+
                      "       tenant_id          UUID NOT NULL,\n" +

  • How it should be:
    

                return "CREATE TABLE IF NOT EXISTS master (\n" +
                       "       tenant_id          UUID NOT NULL,\n" +

• I see that getTenantSql() is not yet implemented in P2JSQLServer2008Dialect. I believe there aren't any clients that will make use of it at the moment, but my question is: should that part stay unimplemented for now, and when we'll need it, we'll go and implement it? Or should we approach this with another strategy?
• The first line of javadoc in Dialect.TenantSQL has over 110 characters.

From a logical point of view, I have no observations. In terms of testing, did everything go well?

Radu Apetrii wrote:

Review for 8989a:

• This is like the smallest complaint ever, but in MariaDbLenientDialect and in P2JH2Dialect, the return statement of the functions getCreateMasterTable() and getCreateDatabasesTable() is a bit misaligned.

OK, thank you for noticing this. It was the result of copy/paste and the IDE trying to be smarter and tab-aligning (3x spaces) the strings instead of keeping the indent from previous string. Fixed.

• I see that getTenantSql() is not yet implemented in P2JSQLServer2008Dialect. I believe there aren't any clients that will make use of it at the moment, but my question is: should that part stay unimplemented for now, and when we'll need it, we'll go and implement it? Or should we approach this with another strategy?

I added an implementation for SQL Server, too. However, because MS prefers not to implement IF NOT EXISTS, the code for achieving the same is much more complex.

• The first line of javadoc in Dialect.TenantSQL has over 110 characters.

Sorry, I see it at exactly 110.

From a logical point of view, I have no observations. In terms of testing, did everything go well?

All the tests were successful. I insisted on PSQL as being the target and H2 - to avoid regressions. I was not able to test MSSQL ATM. Maybe I will do this these days. Except that, no regressions.

BTW, I updated the Multi-Tenancy to include the information on supported dialects and basic instructions on how to configure it.

Lorian, Greg asked that we test trunk/15658 with the customer harness before we push it to customers. Since this is not working for Ovidiu at the moment, would you please run a harness test with this revision and report the result here? Thanks.

Ovidiu Maxiniuc wrote:

BTW, I updated the Multi-Tenancy to include the information on supported dialects and basic instructions on how to configure it.

Ovidiu, I read through this section of the documentation. One thing that was not fully clear to me: with 8989a now merged to trunk, does the absence of the landlord_database_url element in directory.xml now represent an error, or will the runtime default to its pre-8989a behavior of creating an H2 landlord database?

Since multiple people are now testing with multi-tenancy enabled, we need to know if those environments will break when this feature is picked up.

Eric Faulhaber wrote:

Ovidiu, I read through this section of the documentation. One thing that was not fully clear to me: with 8989a now merged to trunk, does the absence of the landlord_database_url element in directory.xml now represent an error, or will the runtime default to its pre-8989a behavior of creating an H2 landlord database?

• if the landlord_database_url is not set, the multi-tenancy is NOT enabled, not an error. Just running in regular ST mode where all tenant-related functionalities are disabled.
• if it contains an invalid string, the FWD server will start but when the string fails to be parsed by DriverManager, an error ("Cannot connect to the landlord database due to <error-cause>) will be logged. I have not done more exploratory testing/debugging in this case;

Since multiple people are now testing with multi-tenancy enabled, we need to know if those environments will break when this feature is picked up.

That's cool.
The branch 8989a does not change anything functionally, just adds support for new dialects for storing landlord database.

Eric Faulhaber wrote:

Lorian, Greg asked that we test trunk/15658 with the customer harness before we push it to customers. Since this is not working for Ovidiu at the moment, would you please run a harness test with this revision and report the result here? Thanks.

Tested harness and it was ok ✅.

Trunk rev 15662 was pushed to xfer.