[
https://issues.apache.org/jira/browse/IGNITE-23386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-23386:
---------------------------------------
Description:
Currently, remove() behaves differently from removeAll():
# If remove() argument (key) corresponds to an entry that did not exist or was
already removed, the command does NOT create a new Metastorage revision (so it
behaves like a NO_OP command)
# On the other hand, if all removeAll() keys correspond to non-existing
entries, it DOES create a new Metastorage revision
# In the code of invoke() methods, it can be seen that earlier the same
optimization was also applied to remove-only invokes (no revision would be
created for a no-op remove-only invoke), but now the optimization can never
happen (as we always add a PUT with a key related to idempotency, and PUTs
always cause a new revision to be created)
This looks inconsistently. We should simplify the logic and always create a
Metastorage revision as a result of a command execution, even if the
Metastorage is not changed at all.
> Create revision in Metastorage even if removal has no effect
> ------------------------------------------------------------
>
> Key: IGNITE-23386
> URL: https://issues.apache.org/jira/browse/IGNITE-23386
> Project: Ignite
> Issue Type: Improvement
> Reporter: Roman Puchkovskiy
> Assignee: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3
>
> Currently, remove() behaves differently from removeAll():
> # If remove() argument (key) corresponds to an entry that did not exist or
> was already removed, the command does NOT create a new Metastorage revision
> (so it behaves like a NO_OP command)
> # On the other hand, if all removeAll() keys correspond to non-existing
> entries, it DOES create a new Metastorage revision
> # In the code of invoke() methods, it can be seen that earlier the same
> optimization was also applied to remove-only invokes (no revision would be
> created for a no-op remove-only invoke), but now the optimization can never
> happen (as we always add a PUT with a key related to idempotency, and PUTs
> always cause a new revision to be created)
> This looks inconsistently. We should simplify the logic and always create a
> Metastorage revision as a result of a command execution, even if the
> Metastorage is not changed at all.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
