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