[
https://issues.apache.org/jira/browse/IGNITE-19228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-19228:
---------------------------------------
Description:
h3. 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.
h3. 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.
was:
h3. 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.
h3. What to do
We need to validate:
* forward schema compatibility on commit
* backward compatibility on reads in RW txs
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|IGNITE-19229].
> Schema validation during tx processing: common framework
> --------------------------------------------------------
>
> Key: IGNITE-19228
> URL: https://issues.apache.org/jira/browse/IGNITE-19228
> Project: Ignite
> Issue Type: Improvement
> Reporter: Roman Puchkovskiy
> Assignee: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. 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.
> h3. 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
