You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Vladislav Pyatkov (Jira)" <ji...@apache.org> on 2023/10/31 13:54:00 UTC

[jira] [Commented] (IGNITE-20609) Move last commit timestamp into BinaryRowMessage

    [ https://issues.apache.org/jira/browse/IGNITE-20609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17781368#comment-17781368 ] 

Vladislav Pyatkov commented on IGNITE-20609:
--------------------------------------------

Merged ebb092f0ced589657411d23277606250ef467c6e

> Move last commit timestamp into BinaryRowMessage
> ------------------------------------------------
>
>                 Key: IGNITE-20609
>                 URL: https://issues.apache.org/jira/browse/IGNITE-20609
>             Project: Ignite
>          Issue Type: Task
>            Reporter:  Kirill Sizov
>            Assignee: Vladislav Pyatkov
>            Priority: Major
>              Labels: ignite-3
>             Fix For: 3.0.0-beta2
>
>          Time Spent: 50m
>  Remaining Estimate: 0h
>
> *Motivation*
> UpdateAllCommand now has two maps:
> {{Map<UUID, BinaryRowMessage> rowsToUpdate()}}
> and 
> {{Map<UUID, Long> lastCommitTimestampsLong()}} and the keys in both maps denote to the same set of rows.
> We can get rid of the duplication to *reduce the size of the message* if instead of two maps we had a single one where the new value class would contain both {{BinaryRowMessage}} and last row commit timestamp.
> *Implementation details*
>  # BinaryRowMessage is used in many other places, perhaps we could subsclass it instead of adding more data to the message class itself.
>  # While implementing this task we need to be careful since currently a null BinaryRowMessage is a valid case when we perform DELETE. If we subclass BinaryRowMessage, we should also change the nullability of the row.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)