transaction log logging 0 for NULL INTEGER VALUES

[Patrick Crews]

The transaction log is using 0 as the logged value for NULL INSERT's. It also logs 0 when the INSERTed value = 0.

DROP TABLE IF EXISTS t1;
--enable_warnings
CREATE TABLE t1 (a INT NOT NULL AUTO_INCREMENT, b INT, PRIMARY KEY(a));
INSERT INTO t1 (b) VALUES(NULL);
SELECT PRINT_TRANSACTION_MESSAGE('transaction.log',(select max(entry_offset) from DATA_DICTIONARY.TRANSACTION_LOG_TRANSACTIONS));
transaction_context {
  server_id: 1
  transaction_id: 8
  START_TIMESTAMP
  END_TIMESTAMP
}
statement {
  type: INSERT
  START_TIMESTAMP
  END_TIMESTAMP
  insert_header {
    table_metadata {
      schema_name: "test"
      table_name: "t1"
    }
    field_metadata {
      type: INTEGER
      name: "a"
    }
    field_metadata {
      type: INTEGER
      name: "b"
    }
  }
  insert_data {
    segment_id: 1
    end_segment: true
    record {
      insert_value: "3"
      insert_value: "0" <-- NOT NULL
    }
  }
}

[Patrick Crews (patrick-crews)]

NOTE: The main test case for this is in suite=transaction_log, test = transaction_log_data_types.
./test-run --suite=transaction_log transaction_log_data_types.

The test will be hacked when pushed to the linked branch so that it will fail on such errors.

It should be noted that the transaction log seems to have issues with NULL values for all data types and perhaps a standard 'NULL' value should be created.

See: https://blueprints.launchpad.net/drizzle/+spec/test-transaction-log for additional, related bug reports.

[Patrick Crews (patrick-crews)]

Same behavior for BIGINT (0 vs. NULL)

[Patrick Crews (patrick-crews)]

DECIMAL show similar behavior:
transaction_log data for a NULL INSERT into DECIMAL(5,2) column

+ insert_data {
+ segment_id: 1
+ end_segment: true
+ record {
+ insert_value: "3"
+ insert_value: "0.00"
+ }
+ }
+}

[David Shrewsbury (dshrews)]

This is probably related to the same issue affecting bug 594876.