- v1.0.0-latest-prod
|
Tip
|
The 2.x versions are Spring Boot 3 compatible. |
This version includes all changes up to 2.1.0 Release Notes
The Tenant Services 2.1.0 Search Group migration scripts, particularly db/sql/tenant-search-group-migration.sql/db/sql/tenant-search-group-migration-oracle.sql, had a few different issues that are rectified with new scripts in this release.
Generally speaking, the recommendation is for clients who are coming from TenantServices versions before 2.1.0 to skip 2.1.0 and directly upgrade to 2.1.1 to bypass the issues with the 2.1.0 migration scripts.
Below is a section describing the bugs and applied fixes for context, but clients can skip to the migration steps section to see required actions.
db/changelog/tenant.oracle.changelog-master.yaml included db/sql/tenant-search-group-migration-oracle.sql by default, which is not correct as it should only have been applied if explicitly included by a client.
The script failed to run altogether on MariaDB and MySQL, as they use 1-based string positioning for functions like SUBSTRING but the script was assuming 0-based, which resulted in invalid values.
A new script db/sql/tenant-search-group-migration-v4-mysqlmariadb.sql has been introduced, which fully replaces the previous script.
It uses the correct SUBSTRING semantics, and also addresses the timestamp issue discussed below as well as the duplicate persistence message issue.
This is a minor issue, but the blc_notification_state.change_timestamp and blc_tenant_catalog.updated_timestamp fields on the newly inserted entities were set to 'now' instead of the traditional '1 hour before now' value.
In scenarios where the migration script was run immediately before application startup, these timestamps could fall within RetryProperties.initialFaultThreshold and therefore the corresponding messages would not be sent by RetryHandler for several minutes.
During this period, the admin would be broken due to the missing catalogs.
After a few minutes, those messages do get sent and the entities get synchronized correctly in the system, and the admin starts working again.
Ultimately, the state ends up being correct, but we should avoid the temporary broken period.
The script added a notification entry into the blc_notification_state table which could contain a duplicate PERSISTENCE state for an Application. This could cause issues as the timestamps between the two notifications could misalign the logic used to create the persistence notifications.
There should only be one entry for a particular container/entity_type/notification_name in the table.
For clients running PostgreSQL
Add the db/sql/tenant-search-group-migration.sql migration script to tenant.flexdemo.postgresql.changelog-master after any scripts that currently load Tenants and Applications
This establishes all the key records as described here
Add the new db/sql/tenant-search-group-migration-v4-postgresql.sql script to tenant.flexdemo.postgresql.changelog-master immediately afterward
This will fix the timestamps in those newly inserted entities, as well as the duplicate PERSISTENCE notification states
|
Note
|
The back-to-back execution of these scripts is relevant because the script’s designed to only affect records if they have a timestamp newer than 15 minutes old.
If the records are allowed to get older than that before the application is run, then they will naturally not be susceptible to the RetryProperties.initialFaultThreshold issue and don’t need rectification anyway.
|
For clients running Oracle
Add the db/sql/tenant-search-group-migration-oracle.sql migration script to tenant.flexdemo.oracle.changelog-master after any scripts that currently load Tenants and Applications
This establishes all the key records as described here
The script no longer being included by default helps ensure it will only apply where you explicitly include it.
Add the new db/sql/tenant-search-group-migration-v4-oracle.sql script to tenant.flexdemo.oracle.changelog-master immediately afterward
This will fix the timestamps in those newly inserted entities, as well as the duplicate PERSISTENCE notification states
|
Note
|
The back-to-back execution of these scripts is relevant because the script’s designed to only affect records if they have a timestamp newer than 15 minutes old.
If the records are allowed to get older than that before the application is run, then they will naturally not be susceptible to the RetryProperties.initialFaultThreshold issue and don’t need rectification anyway.
|
For clients running MariaDB or MySQL
The original 2.1.0 migration script would not have run successfully on these platforms in the first place.
Therefore, the recommendation is to not use or include that original script in any way.
Instead, add db/sql/tenant-search-group-migration-v4-mysqlmariadb.sql to tenant.flexdemo.mariadb.changelog-master or tenant.flexdemo.mysql.changelog-master (after any scripts that currently load Tenants and Applications).
This will serve as an all-in-one fix.