You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Kirill Tkalenko (Jira)" <ji...@apache.org> on 2024/10/04 05:59:00 UTC

[jira] [Updated] (IGNITE-23307) Deal with getting timestamp for compacted revision

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

Kirill Tkalenko updated IGNITE-23307:
-------------------------------------
    Description: 
We need to figure out what to do with methods *org.apache.ignite.internal.metastorage.server.KeyValueStorage#timestampByRevision* and *org.apache.ignite.internal.metastorage.server.KeyValueStorage#revisionByTimestamp* after compaction.

Let's look at an example, let's say we have keys with the following revisions:
# "foo" [1, 3, 5]
# "bar" [1]
# "one" [2]

Let's say there was a compaction on revision 6, and now the key has the following revisions:
# "foo" [5]
# "bar" [1]
# "one" [2]

Options like the above methods should work:
* Ignoring key revisions:
# *KeyValueStorage#timestampByRevision* - will throw *CompactedException* when requesting a revision less than or equal to 6.
# *KeyValueStorage#revisionByTimestamp* - will return *-1* if the time is less than the time of the 7th storage revision.
* Taking into account key revisions:
# *KeyValueStorage#timestampByRevision* - will throw *CompactedException* only when there are no keys with a compacted revision. From the example above it will throw an exception for revisions 3, 4 and 36and return a value for the rest.
# *KeyValueStorage#revisionByTimestamp* - will return the timestamp it finds.

I am for option "Ignoring key revisions", it looks simple and clear.

{color:#DE350B}Update:{color}
After thinking and discussing with colleagues, we decided to add a timestamp to *org.apache.ignite.internal.metastorage.Entry* (IGNITE-23348) and it will throw *CompactedException* when invoking methods *KeyValueStorage#timestampByRevision* and *KeyValueStorage#revisionByTimestamp* if we will find out that the revision has already been compacted.

  was:
We need to figure out what to do with methods *org.apache.ignite.internal.metastorage.server.KeyValueStorage#timestampByRevision* and *org.apache.ignite.internal.metastorage.server.KeyValueStorage#revisionByTimestamp* after compaction.

Let's look at an example, let's say we have keys with the following revisions:
# "foo" [1, 3, 5]
# "bar" [1]
# "one" [2]

Let's say there was a compaction on revision 6, and now the key has the following revisions:
# "foo" [5]
# "bar" [1]
# "one" [2]

Options like the above methods should work:
* Ignoring key revisions:
# *KeyValueStorage#timestampByRevision* - will throw *CompactedException* when requesting a revision less than or equal to 6.
# *KeyValueStorage#revisionByTimestamp* - will return *-1* if the time is less than the time of the 7th storage revision.
* Taking into account key revisions:
# *KeyValueStorage#timestampByRevision* - will throw *CompactedException* only when there are no keys with a compacted revision. From the example above it will throw an exception for revisions 3, 4 and 36and return a value for the rest.
# *KeyValueStorage#revisionByTimestamp* - will return the timestamp it finds.

I am for option "Ignoring key revisions", it looks simple and clear.


> Deal with getting timestamp for compacted revision
> --------------------------------------------------
>
>                 Key: IGNITE-23307
>                 URL: https://issues.apache.org/jira/browse/IGNITE-23307
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Kirill Tkalenko
>            Assignee: Kirill Tkalenko
>            Priority: Major
>              Labels: ignite-3
>
> We need to figure out what to do with methods *org.apache.ignite.internal.metastorage.server.KeyValueStorage#timestampByRevision* and *org.apache.ignite.internal.metastorage.server.KeyValueStorage#revisionByTimestamp* after compaction.
> Let's look at an example, let's say we have keys with the following revisions:
> # "foo" [1, 3, 5]
> # "bar" [1]
> # "one" [2]
> Let's say there was a compaction on revision 6, and now the key has the following revisions:
> # "foo" [5]
> # "bar" [1]
> # "one" [2]
> Options like the above methods should work:
> * Ignoring key revisions:
> # *KeyValueStorage#timestampByRevision* - will throw *CompactedException* when requesting a revision less than or equal to 6.
> # *KeyValueStorage#revisionByTimestamp* - will return *-1* if the time is less than the time of the 7th storage revision.
> * Taking into account key revisions:
> # *KeyValueStorage#timestampByRevision* - will throw *CompactedException* only when there are no keys with a compacted revision. From the example above it will throw an exception for revisions 3, 4 and 36and return a value for the rest.
> # *KeyValueStorage#revisionByTimestamp* - will return the timestamp it finds.
> I am for option "Ignoring key revisions", it looks simple and clear.
> {color:#DE350B}Update:{color}
> After thinking and discussing with colleagues, we decided to add a timestamp to *org.apache.ignite.internal.metastorage.Entry* (IGNITE-23348) and it will throw *CompactedException* when invoking methods *KeyValueStorage#timestampByRevision* and *KeyValueStorage#revisionByTimestamp* if we will find out that the revision has already been compacted.



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