Page History

...

Here we add the following requirements:

1. A DDL operation must be linearized wrt any DML operation (in other words, if we treat a DDL as a ‘transaction’, it is strictly serializable). This means that a DDL operation immediately affects any transactions that started before it, and new transactions will start using the new schema. No transaction can have reads/writes run both on the old schema and the new schema AND have the possibility to detect that they were executed on different schemasHandling of a transborder transaction should not produce any weird (from the point of view of the user) behavior. An example of a weirdness is if a transaction is run on more than one schema during its life, or it looks (to other transactions) that it did so.
2. After a CREATE TABLE, the created table must be available for any transaction started before the CREATE TABLE was executed.
3. If an ALTER TABLE happens after a transaction was started and only later (after the DDL) the table gets enlisted in the transaction, the transaction should not be aborted due to the schema change.

...

1. A client comes and tries to execute an operation in a transaction (it sends its schema version clientSV in each tuple it sends in the request)
2. The tx coordinator gets the request, takes baseTs=tableEnlistTs(table, tx), then takes a schema version tableEnlistSV corresponding to the ts and, if clientSV does not match tableEnlistSV, returns an error to the client (the error contains tableEnlistSV); by getting the error, the client retries its request using tableEnlistSV. The coordinator caches tableEnlistSV for each table in each transaction.
3. If the client request validation succeeds, the coordinator sends tableEnlistSV to the primary (either implicitly [in binary tuples of the request] or explicitly)
4. (As a result, for the same table in the same tx, there will be the same tableEnlistSV)
5. The primary uses tableEnlistSV as I (initial schema) when validating schema compatibility for each transaction read/write operation
6. The coordinator uses tableEnlistSV as I (initial schema) when validating schema compatibility during commit
7. If the transaction is aborted due to schema validation failure (items 5 and 6), an error code is returned to the client that says that the transaction should be retried
8. If the client gets a retriable error code, it retries the transaction

The diagram illustrates the following:

• Client schema version validation and refresh
• Successful writes
• Schema validation at commit
• Retry of an aborted transaction

When schema changes are validated

...