[jira] [Updated] (IGNITE-18360) Migrate storage to new Binary Tuple format

["Mikhail Pochatkin (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-18360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mikhail Pochatkin updated IGNITE-18360:
---------------------------------------
    Component/s: 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
>          Components: jdbc
>            Reporter: Konstantin Orlov
>            Priority: Major
>              Labels: ignite-3
>
> 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)