[
https://issues.apache.org/jira/browse/IGNITE-21003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-21003:
---------------------------------------
Description:
This issue is to think about the problem and design it first, not about
implementing it right away.
Currently, for an RW transaction, we take schema at the beginning of the
transaction and run the whole transaction on that schema (indices are an
exception, but this is not visible to the end user). The transaction still
notices most schema changes (if a change happens before a read/write in the
transaction, the transaction gets aborted), but it does not notice a table
created after the transaction had started.
IGNITE-20107 addressed this issue, but it was decided that we need to design
this in more depth.
An alternative is to always use the latest schema on each operation (still
having schema validation). This might have some downsides/bring difficulties:
# Same query might return data with different schemas
# It's not clear against which schema to validate the current schema at
execution of each operation (probably, still against the initial one, defined
as Max(txStartTs, tableCreationTs))
# A query would have to use the same query timestamp on each node executing
its fragments, so it would have to propagate this timestamp
The schema synchronization design was created starting with an assumption that
the schema is taken for the start of a transaction, so the design should be
revised carefully when switching to the proposed one.
> Switch to the 'always use current schema' approach
> --------------------------------------------------
>
> Key: IGNITE-21003
> URL: https://issues.apache.org/jira/browse/IGNITE-21003
> Project: Ignite
> Issue Type: Improvement
> Reporter: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
>
> This issue is to think about the problem and design it first, not about
> implementing it right away.
> Currently, for an RW transaction, we take schema at the beginning of the
> transaction and run the whole transaction on that schema (indices are an
> exception, but this is not visible to the end user). The transaction still
> notices most schema changes (if a change happens before a read/write in the
> transaction, the transaction gets aborted), but it does not notice a table
> created after the transaction had started.
> IGNITE-20107 addressed this issue, but it was decided that we need to design
> this in more depth.
> An alternative is to always use the latest schema on each operation (still
> having schema validation). This might have some downsides/bring difficulties:
> # Same query might return data with different schemas
> # It's not clear against which schema to validate the current schema at
> execution of each operation (probably, still against the initial one, defined
> as Max(txStartTs, tableCreationTs))
> # A query would have to use the same query timestamp on each node executing
> its fragments, so it would have to propagate this timestamp
> The schema synchronization design was created starting with an assumption
> that the schema is taken for the start of a transaction, so the design should
> be revised carefully when switching to the proposed one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
