From c586aaffee46b4e94e511e0274d2505e4a10dd3c Mon Sep 17 00:00:00 2001
From: Alex Chi <iskyzh@gmail.com>
Date: Sun, 28 Jan 2024 21:13:10 +0800
Subject: [PATCH] add your solutions

Signed-off-by: Alex Chi <iskyzh@gmail.com>
---
 README.md                                        |  4 ++++
 SOLUTIONS.md                                     | 11 +++++++++++
 mini-lsm-book/src/week3-01-ts-key-refactor.md    |  1 +
 .../src/week3-02-snapshot-read-part-1.md         |  7 +++++++
 .../src/week3-03-snapshot-read-part-2.md         | 16 ++++++++++++----
 5 files changed, 35 insertions(+), 4 deletions(-)
 create mode 100644 SOLUTIONS.md

diff --git a/README.md b/README.md
index 4210960..3e3009c 100644
--- a/README.md
+++ b/README.md
@@ -14,6 +14,10 @@ You may join skyzh's Discord server and study with the mini-lsm community.
 
 [![Join skyzh's Discord Server](https://dcbadge.vercel.app/api/server/ZgXzxpua3H)](https://skyzh.dev/join/discord)
 
+**Add Your Solution**
+
+If you finished at least one full week of this tutorial, you can add your solution to the community solution list at [SOLUTIONS.md](./SOLUTIONS.md). You can submit a pull request and we might do a quick review of your code in return of your hard work.
+
 ## Development
 
 ```
diff --git a/SOLUTIONS.md b/SOLUTIONS.md
new file mode 100644
index 0000000..5b5730a
--- /dev/null
+++ b/SOLUTIONS.md
@@ -0,0 +1,11 @@
+# Mini-LSM Community Solutions
+
+You can add your solution to this page once you finish any full week of the tutorial. You may have a one-sentence introduction of what you have done in your solution and any special functionalities you have implemented.
+
+## Week 1
+
+## Week 2
+
+## Week 3
+
+* [skyzh/mini-lsm-solution-checkpoint](https://github.com/skyzh/mini-lsm-solution-checkpoint): The author's solution of Mini-LSM.
diff --git a/mini-lsm-book/src/week3-01-ts-key-refactor.md b/mini-lsm-book/src/week3-01-ts-key-refactor.md
index 4753771..573f0ed 100644
--- a/mini-lsm-book/src/week3-01-ts-key-refactor.md
+++ b/mini-lsm-book/src/week3-01-ts-key-refactor.md
@@ -3,6 +3,7 @@
 In this chapter, you will:
 
 * Refactor your implementation to use key+ts representation.
+* Make your code compile with the new key representation.
 
 ## Task 0: Use MVCC Key Encoding
 
diff --git a/mini-lsm-book/src/week3-02-snapshot-read-part-1.md b/mini-lsm-book/src/week3-02-snapshot-read-part-1.md
index 8f18fcd..25c106e 100644
--- a/mini-lsm-book/src/week3-02-snapshot-read-part-1.md
+++ b/mini-lsm-book/src/week3-02-snapshot-read-part-1.md
@@ -1,5 +1,12 @@
 # Snapshot Read - Memtables and Timestamps
 
+In this chapter, you will:
+
+* Refactor your memtable/WAL to store multiple versions of a key.
+* Implement the new engine write path to assign each key a timestamp.
+* Make your compaction process aware of multi-version keys.
+* Implement the new engine read path to return the latest version of a key.
+
 During the refactor, you might need to change the signature of some functions from `&self` to `self: &Arc<Self>` as necessary.
 
 ## Task 1: MemTable, Write-Ahead Log, and Read Path
diff --git a/mini-lsm-book/src/week3-03-snapshot-read-part-2.md b/mini-lsm-book/src/week3-03-snapshot-read-part-2.md
index bb306e9..98cd692 100644
--- a/mini-lsm-book/src/week3-03-snapshot-read-part-2.md
+++ b/mini-lsm-book/src/week3-03-snapshot-read-part-2.md
@@ -1,12 +1,16 @@
 # Snapshot Read - Engine Read Path and Transaction API
 
-## Task 1: Store Largest Timestamp in SST
+In this chapter, you will:
 
-## Task 2: Recover Commit Timestamp
+* Finish the read path based on previous chapter to support snapshot read.
+* Implement the transaction API to support snapshot read.
+* Implement the engine recovery process to correctly recover the commit timestamp.
 
-## Task 3: Lsm Iterator with Read Timestamp
+At the end of the day, your engine will be able to give the user a consistent view of the storage key space.
 
-## Task 4: Multi-Version Scan and Get
+## Task 1: Lsm Iterator with Read Timestamp
+
+## Task 2: Multi-Version Scan and Get
 
 For now, inner = `Fused<LsmIterator>`, do not use `TxnLocalIterator`
 
@@ -14,6 +18,10 @@ explain why store txn inside iterator
 
 do not implement put and delete
 
+## Task 3: Store Largest Timestamp in SST
+
+## Task 4: Recover Commit Timestamp
+
 ## 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?