-
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
Martin Skold authoredThe 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