add 3.3 test

Signed-off-by: Alex Chi <iskyzh@gmail.com>
This commit is contained in:
Alex Chi
2024-01-29 20:43:10 +08:00
parent e947e6d8e0
commit c45d6c8261
8 changed files with 289 additions and 3 deletions

View File

@@ -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}}

View File

@@ -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?