Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
Description
Definitions
When a coordinator initiates a transaction, it takes a timestamp beginTs=Ts=Now and sends it to all participants. On first access to a table Q (in this transaction) on a primary replica node, the schema of Q is obtained for moment Ts; this schema is called ‘initial schema’ and associated with this transaction on this node. When a commit of the transaction is processed with commit timestamp Tc, the node obtains the schema of Q again, now at the moment of Tc; this is the ‘commit schema’. If the commit schema is different from the initial schema and not compatible with it (using the notion of the forward compatibility defined below), the commit fails (and the transaction is aborted).
An initial schema is said to be forward-compatible with a commit schema if, having a tuple written with the initial schema, it is enough to know the commit schema to read the tuple.
An initial schema is said to be backward-compatible with a commit schema if the same is true the other way around: having a tuple written with the commit schema, we can read it having just the initial schema.
What to do
We need to validate:
- forward schema compatibility on commit
- backward compatibility on reads in RW txs (this will be done in another task:
IGNITE-19454)
If a schema change is incompatible, the transaction is aborted.
This task is about the implementation of a common framework allowing to do validations using specific validators and using this framework while processing transactions. Only one validator is needed for starters, it will consider all schema changes incompatible.
Real validators will be added in a follow-up task.
Attachments
Issue Links
- split to
-
-
- Resolved
-
- links to
