Skip to content
  • Martin Skold's avatar
    41e7806f
    WL#6146 Extend Ndb conflict exceptions table · 41e7806f
    Martin Skold authored
    The original conflict table is defined like this:
    CREATE TABLE original_table$EX  (
        server_id INT UNSIGNED,
        master_server_id INT UNSIGNED,
        master_epoch BIGINT UNSIGNED,
        count INT UNSIGNED,
        original_table_pk_columns,
        [additional_columns,]
        PRIMARY KEY(server_id, master_server_id, master_epoch, count)
    ) ENGINE=NDB;
    
    Requirements
    ------------
    
      1) Support backwards compatibility so that existing conflict detection users
    needn't change their table schema
         1.1 Mandatory columns may have any names
         1.2 Main table primary key columns may have any names
         1.3 Additional columns sharing names with main table columns are treated as
    user columns.
    
      2) Support use of a reserved column name namespace for metacolumns, allowing
    an arbitrary subset of non-pk main table columns to be recorded
         2.1 NDB$ prefix used for all mandatory (non main table / user data columns)
         2.2 Existing mandatory columns prefixed with NDB$
         2.3 The full user table PK needn't be recorded
         2.4 Matching of main table columns to exceptions table columns to be on the
    basis of name and type.
         2.5 Informative error message to be produces when column name/types mismatch
         2.5.1 NDB$ prefixed column with invalid suffix
         2.5.2 Column type not matching expectation
    
      3) Support recording rejected non-primary key after values in the exceptions
    table where available
         3.1 None, some or all non-primary key after values may be stored.
         3.2 WRITE_ROW events may not have all column after values due to
              i) Logging updated only on the Master
             ii) Master having fewer columns than the Slave
         3.3 UPDATE_ROW events may not have all column after values due to
              i) Logging updated only on the Master
             ii) Master having fewer columns than the Slave
         3.4 DELETE_ROW events have no after values
         3.5 All non primary key main table columns must be NULLABLE or natively
    DEFAULTed in the Exceptions table
    
      4) Support recording optional conflicting operation type
         4.1 e.g. NDB$OP_TYPE INT UNSIGNED NOT NULL
         4.2 Current types : WRITE_ROW, UPDATE_ROW, DELETE_ROW
    
      5) Support recording optional conflict cause
         5.1 e.g. NDB$CFT_CAUSE INT UNSIGNED NOT NULL
         5.2 Current causes :
             ROW_DOES_NOT_EXIST (UPDATE_ROW, WRITE_ROW)
             ROW_ALREADY_EXISTS (WRITE_ROW)
             DATA_IN_CONFLICT   (UPDATE_ROW, DELETE_ROW)
             TRANS_IN_CONFLICT  (*)
         5.3 Note that TRANS_IN_CONFLICT obscures per-row causation information, so
             perhaps warn when a table with transactional conflict detection is
             configured with a conflict cause column in the exceptions table
    
      6) Support recording optional originating transaction id info
         6.1 e.g. NDB$ORIG_TRANSID BIGINT UNSIGNED NOT NULL
         6.2 Note that this is most likely to be useful with transactional conflict
             detection, so perhaps warn if it's configured for a non-transactional
             algorithm
    
      7) Additional added functionality
         7.1 Support for referencing old/new values of non-primary key columns
           <column_name>$old and <column_name>$new (same as just writing <column_name>) columns
          in the extended exceptions will reference old and new values in update operations. For
         write operations the old value will be NULL and for delete operations the new value will be NULL.
         Checks will be made that such columns will
         have to be declared as nullable or with a default value (native ndb default) and cannot be part of the primary key.
         7.2 NDB$OP_TYPE will be also aligned with ENUM('WRITE_ROW','UPDATE_ROW', 'DELETE_ROW') NOT NULL
         7.3  NDB$CFT_CAUSE will also be aligned with
    ENUM('ROW_DOES_NOT_EXIST','ROW_ALREADY_EXISTS','DATA_IN_CONFLICT','TRANS_IN_CONFLICT') NOT NULL
    41e7806f
    WL#6146 Extend Ndb conflict exceptions table
    Martin Skold authored
    The original conflict table is defined like this:
    CREATE TABLE original_table$EX  (
        server_id INT UNSIGNED,
        master_server_id INT UNSIGNED,
        master_epoch BIGINT UNSIGNED,
        count INT UNSIGNED,
        original_table_pk_columns,
        [additional_columns,]
        PRIMARY KEY(server_id, master_server_id, master_epoch, count)
    ) ENGINE=NDB;
    
    Requirements
    ------------
    
      1) Support backwards compatibility so that existing conflict detection users
    needn't change their table schema
         1.1 Mandatory columns may have any names
         1.2 Main table primary key columns may have any names
         1.3 Additional columns sharing names with main table columns are treated as
    user columns.
    
      2) Support use of a reserved column name namespace for metacolumns, allowing
    an arbitrary subset of non-pk main table columns to be recorded
         2.1 NDB$ prefix used for all mandatory (non main table / user data columns)
         2.2 Existing mandatory columns prefixed with NDB$
         2.3 The full user table PK needn't be recorded
         2.4 Matching of main table columns to exceptions table columns to be on the
    basis of name and type.
         2.5 Informative error message to be produces when column name/types mismatch
         2.5.1 NDB$ prefixed column with invalid suffix
         2.5.2 Column type not matching expectation
    
      3) Support recording rejected non-primary key after values in the exceptions
    table where available
         3.1 None, some or all non-primary key after values may be stored.
         3.2 WRITE_ROW events may not have all column after values due to
              i) Logging updated only on the Master
             ii) Master having fewer columns than the Slave
         3.3 UPDATE_ROW events may not have all column after values due to
              i) Logging updated only on the Master
             ii) Master having fewer columns than the Slave
         3.4 DELETE_ROW events have no after values
         3.5 All non primary key main table columns must be NULLABLE or natively
    DEFAULTed in the Exceptions table
    
      4) Support recording optional conflicting operation type
         4.1 e.g. NDB$OP_TYPE INT UNSIGNED NOT NULL
         4.2 Current types : WRITE_ROW, UPDATE_ROW, DELETE_ROW
    
      5) Support recording optional conflict cause
         5.1 e.g. NDB$CFT_CAUSE INT UNSIGNED NOT NULL
         5.2 Current causes :
             ROW_DOES_NOT_EXIST (UPDATE_ROW, WRITE_ROW)
             ROW_ALREADY_EXISTS (WRITE_ROW)
             DATA_IN_CONFLICT   (UPDATE_ROW, DELETE_ROW)
             TRANS_IN_CONFLICT  (*)
         5.3 Note that TRANS_IN_CONFLICT obscures per-row causation information, so
             perhaps warn when a table with transactional conflict detection is
             configured with a conflict cause column in the exceptions table
    
      6) Support recording optional originating transaction id info
         6.1 e.g. NDB$ORIG_TRANSID BIGINT UNSIGNED NOT NULL
         6.2 Note that this is most likely to be useful with transactional conflict
             detection, so perhaps warn if it's configured for a non-transactional
             algorithm
    
      7) Additional added functionality
         7.1 Support for referencing old/new values of non-primary key columns
           <column_name>$old and <column_name>$new (same as just writing <column_name>) columns
          in the extended exceptions will reference old and new values in update operations. For
         write operations the old value will be NULL and for delete operations the new value will be NULL.
         Checks will be made that such columns will
         have to be declared as nullable or with a default value (native ndb default) and cannot be part of the primary key.
         7.2 NDB$OP_TYPE will be also aligned with ENUM('WRITE_ROW','UPDATE_ROW', 'DELETE_ROW') NOT NULL
         7.3  NDB$CFT_CAUSE will also be aligned with
    ENUM('ROW_DOES_NOT_EXIST','ROW_ALREADY_EXISTS','DATA_IN_CONFLICT','TRANS_IN_CONFLICT') NOT NULL
Loading