Class ActiveMonitorDbMigration

  • All Implemented Interfaces:
    AutoCloseable

    public class ActiveMonitorDbMigration
    extends ADbMigration
    Class with migration utils for ActiveMonitor database.

    This class offers a main method to run that will migrate an existing ActiveMonitor database to its new structure for the current version.
    This migrates a database with schema version 3.3, used by ActiveMonitor 3.3 and 3.4, to the current version.

    Haw to use it:
    Execute the main(String...) method. It uses connection information specified in sentinel.db.properties to connect to the database.

    This "script" suggests a solution to migrate your existing database. This must be read as advice on what to change more than an explicit tool for migration.
    It does not handle all types of database and is not designed to consider extra database customizations.
    Operations are performed in-place, meaning that it changes an existing database.It is strongly recommended to backup your database before running the migration process.
    Read the main(String...) method content to get the list of all transformations applied to the database. Each transformation is handled by a dedicated method, whose purpose is documented as most as possible.

    Main changes performed for this migration

    • Prefixing all table names
    • Renaming fields not to use reserved keywords as column names
    • Migrate required fields and tables for the new workflow system

    For more information, consult our migration notes and release notes.

    Author:
    QuartetFS
    • Constructor Detail

      • ActiveMonitorDbMigration

        public ActiveMonitorDbMigration()
    • Method Detail

      • main

        public static void main​(String... args)
                         throws SQLException
        Runs the migration for ActiveMonitor database.

        This migration is a lot heavier than preceding.
        A lot of operations involves migrating tables and columns to support automatically main databases systems, as well as being able to put all tables in the same schema.
        Hibernate was also migrated to a new major version, involving some changes on its internal behavior.
        Finally, new features of ActiveMonitor require new tables or columns, particularly the workflow system persisting schemas for all entities.

        Reading the following code and the doc of the called methods will give an overview of the operations performed to migrate the database.
        Given the complexity for some operations, some may not perform any action, or be restricted as an example to H2 database.

        Parameters:
        args - (nane expected)
        Throws:
        SQLException - if the connection has issues
      • prefixTables

        public void prefixTables()
        Prefixes all existing tables by ""activemonitor_"".

        This allows to merge multiple projects in the same schema.

      • updateGeneratedIds

        public void updateGeneratedIds()
        Updates definitions for columns with generated ids.

        With update to Hibernate 5.1, strategy to generate ids changed from various sequences to a unique sequence, named HIBERNATE_SEQUENCE - for databases supporting sequence (see https://docs.jboss.org/hibernate/orm/5.1/userguide/html_single/Hibernate_User_Guide.html#identifiers-generators-auto).
        This removes all default values for columns with ids and creates the main Hibernate sequence, starting at the correct value (max of all id columns).

      • renameColumns

        public void renameColumns()
        Renames columns whose names conflicts with some keywords in one or many RDBMS.
      • updateColumnTypes

        public void updateColumnTypes()
        Updates column types for attributes that were misusing "columnDefinition" attribute of Column.

        This was enforcing a specific type, not supported by all RDBMS. It is replaced by the correct type and relies on the Dialect to use the appropriate DB type.

      • renameConstraints

        public void renameConstraints()
        Renames column constraints between tables.

        For DBOs joining other stored objects, Hibernate generates a constraint between the columns taking part in the join. However, without hint, Hibernate generates a hash value from various elements, not really human readable.
        This is an issue as soon as Hibernate refers to them in ConstraintViolationException. To help with this debugging, foreign keys were given readable names.

      • migrateDbVersion

        public void migrateDbVersion()
        Updates the database version schema.

        This is required because the version number changed with delay, because it was missed in 3.4.0 release.

      • addPropertiesFieldToMonitors

        public void addPropertiesFieldToMonitors()
        Adds a new column storing properties encoded in a string to the monitors table.
      • createWorkflowTable

        public void createWorkflowTable()
        Creates the new table for workflow configuration system.

        This is inspired from the work performed by Hibernate when creating the table from scratch.

        1. It creates the table itself, using auto_increment for ids.
        2. As mentionned by renameConstraints(), it creates constraints for join to audit table.
        3. It creates a unicity constraint on the logical key (entityType, entityId), ensuring that only one version is live - adding deleted to null for that purpose
      • migrateParameterWorkflowConfigurations

        public void migrateParameterWorkflowConfigurations()
        Migrates the existing table with workflow schemas for parameters to the new table.

        This reads every entry of parameter workflow table and creates corresponding entries in the new table.
        This is all performed with a single audit entry, as user _script_.

      • removeParameterWorkflowTable

        public void removeParameterWorkflowTable()
        Removes the previous table storing workflow schemas for parameters only.