@@ -105,7 +105,6 @@ Now that we have a timestamp in the key, and when creating the iterators, we wil
|
||||
|
||||
When you check if a user key is in a table, you can simply compare the user key without comparing the timestamp.
|
||||
|
||||
At this point, you should build your implementation and pass all week 1 test cases. We will make the engine fully multi-version and pass all test cases in the next two chapters.
|
||||
|
||||
At this point, you should build your implementation and pass all week 1 test cases. All keys stored in the system will use `TS_DEFAULT` (which is timestamp 0). We will make the engine fully multi-version and pass all test cases in the next two chapters.
|
||||
|
||||
{{#include copyright.md}}
|
||||
|
||||
@@ -22,6 +22,8 @@ do not implement put and delete
|
||||
|
||||
## Task 4: Recover Commit Timestamp
|
||||
|
||||
We do not have test cases for this section. You should pass all persistence tests from previous chapters (2.5 and 2.6) after finishing this section.
|
||||
|
||||
## Test Your Understanding
|
||||
|
||||
* So far, we have assumed that our SST files use a monotonically increasing id as the file name. Is it okay to use `<level>_<begin_key>_<end_key>_<max_ts>.sst` as the SST file name? What might be the potential problems with that?
|
||||
|
||||
Reference in New Issue
Block a user