[
https://issues.apache.org/jira/browse/IGNITE-20345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-20345:
-----------------------------------------
Description:
There exists two types of BinaryRows: key-only rows used for PK lookups and
full rows used for everything else. The main problem with this approach is that
it is impossible to distinguish between them by just looking at the type (it is
the same for both), so it is always identified by context (see
{{ColumnsExtractor}} usages). This is a quite fragile approach, because it is
very easy to make a mistake when extracting keys or values from such rows.
Instead, I propose to use {{BinaryTuple}} instead of key-only rows and only use
{{BinaryRow}} instance for full rows. This way it will always be clear when we
have a PK or a full row by simply looking at the type.
was:There exists two types of BinaryRows:
> Remove the notion of key-only binary rows from PartitionReplicaListener
> -----------------------------------------------------------------------
>
> Key: IGNITE-20345
> URL: https://issues.apache.org/jira/browse/IGNITE-20345
> Project: Ignite
> Issue Type: Task
> Reporter: Aleksandr Polovtcev
> Priority: Major
> Labels: ignite-3
>
> There exists two types of BinaryRows: key-only rows used for PK lookups and
> full rows used for everything else. The main problem with this approach is
> that it is impossible to distinguish between them by just looking at the type
> (it is the same for both), so it is always identified by context (see
> {{ColumnsExtractor}} usages). This is a quite fragile approach, because it is
> very easy to make a mistake when extracting keys or values from such rows.
> Instead, I propose to use {{BinaryTuple}} instead of key-only rows and only
> use {{BinaryRow}} instance for full rows. This way it will always be clear
> when we have a PK or a full row by simply looking at the type.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
