[
https://issues.apache.org/jira/browse/IGNITE-18360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-18360:
--------------------------------------
Component/s: (was: jdbc)
> Migrate storage to new Binary Tuple format
> ------------------------------------------
>
> Key: IGNITE-18360
> URL: https://issues.apache.org/jira/browse/IGNITE-18360
> Project: Ignite
> Issue Type: Improvement
> Reporter: Konstantin Orlov
> Assignee: Vadim Pakhnushev
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> The Binary Tuple Format was introduced in
> [IEP-92|https://cwiki.apache.org/confluence/display/IGNITE/IEP-92%3A+Binary+Tuple+Format]
> as replacement of
> [IEP-54|https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach]
> Binary Row. However, the Ignite's core is still operating rows in BinaryRow
> format. Let's start the migration to the new format.
> Under current ticket it's proposed to migrate the storage only, as these
> changes looks predictable and isolated, whereas it allows to start migration
> in SQL engine as well.
> The migration plan is as follow:
> # Introduce new entity named TableRow.
> Unlike the indexes, the table may evolve over time, thus schema of the binary
> tuple may change as well. To make the storage a schema agnostic, it's
> proposed to store only the version of the schema and a ByteBuffer
> representing the data in the Binary Tuple format.
> # Migrate all table-related storage interfaces and PartitionListener to the
> new format
> # Make conversion in the PartitionReplicaListener from BinaryRow to TableRow
> and vice versa on the edge Replica-Storage integration (in the context of
> this issue I consider the PartitionListener as part of the storage).
> PartitionReplicaListener (PRL) seems to be a good choice to make such a
> conversion because of 1) current implementation of row comparison for
> deleteExact operation can't properly handle the schema changes, and thus the
> notion of the schema has to be brought to this level, and 2) PRL is build
> upon async calls, so it will be easy to incorporate awaiting of schema in
> case the node stales a bit.
> NB: during conversion, I would prefer to restore the logical order of the
> columns and build the tuple in that order, rather than keep the physical
> order of BinaryRow
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
