[ 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)