DROP SCHEMA/TABLE IF EXISTS being logged even if the object didn't exist

[Patrick Crews]

If you issue a DROP SCHEMA IF EXISTS $schema, the transaction log is recording this as DROP SCHEMA $schema.

This is problematic as trying to execute the SQL from this would result in an error *and* the log is recording something that didn't actually happen.

I'll create a branch with a test-case shortly, but here is an example.

./test.run --start-and-exit --drizzled=--transaction-log.enable
DROP SCHEMA IF EXISTS bobo;

select print_transaction_message('transaction.log',(select max(entry_offset) from data_dictionary.transaction_log_entries));
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| print_transaction_message('transaction.log',(select max(entry_offset) from data_dictionary.transaction_log_entries)) |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| transaction_context {
  server_id: 1
  transaction_id: 772
  start_timestamp: 1289563680419957
  end_timestamp: 1289563680419970
}
statement {
  type: DROP_SCHEMA
  start_timestamp: 1289563680419967
  end_timestamp: 1289563680419970
  drop_schema_statement {
    schema_name: "bobo"
  }
}
 |
+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0 sec)

[Patrick Crews (patrick-crews)]

Also happens for DROP TABLE IF

[Patrick Crews (patrick-crews)]

transaction_log.transaction_log_drop.test has been updated.

Sadly we had a test case in there, but I didn't flag the behavior as a bug until now. Added a DROP SCHEMA query to the bug's test case and updated the commenting to indicate that this is attached to this bug.

[Patrick Crews (patrick-crews)]

grrr. I meant updated in the attached branch. It needs to be re-recorded once behavior is correct, so no .result provided.

[David Shrewsbury (dshrews)]

The proto definition for a DROP SCHEMA statement is missing a boolean to track whether or not the IF EXISTS clause was used.

[David Shrewsbury (dshrews)]

Apparently I concentrated too much on the description and not the title before I posted my last comment.

I don't believe that a DROP SCHEMA/TABLE should be logged at all to the transaction log if it did not drop anything. This is confusing behavior, in my opinion. Are we logging the db changes, or are we logging the statements regardless of their effects? I think it should be the db changes only.

Confusingly, the DropTable protobuf message carries an if_exists_clause boolean to indicate if the IF EXISTS clause was used (DropSchema does not). I intend to remove this boolean and only log these statements if an actual change was made. As a side effect of this, output from the transaction_reader will never produce an IF EXISTS clause because it should never be needed.