Date: 2026-05-29
Time: 06:42
I'll work from the file content provided.
log-structured-hash-table/bitcask.py — The implementation under test; understanding HEADER_FMT, the segment rotation logic, and compaction algorithm will clarify why tests use specific byte offsets and size thresholdslog-structured-hash-table/test_bitcask.py — The project's own unit tests, likely testing internals and edge cases that the tester harness intentionally skipshash-index-storage/bitcask.py — A separate Bitcask implementation in the repo; comparing the two reveals how the same DDIA concept can be implemented with different trade-offsbitcask-binary-format — The on-disk record format (HEADER_FMT, CRC, key-length, value-length, payload) is central to tests 4 and 6; understanding the exact byte layout explains the magic offsetslog-structured-hash-table/bitcask.py:compact — The compaction algorithm determines what "stale entries removed" means and how segment files are rewritten, which directly affects tests 1, 3, 7, and 8tester-tests-public-contract — testertest*.py files test the public API contract of each implementation; they import only public symbols (plus format constants needed for fault injection)bitcask-get-returns-none-for-missing — BitcaskStore.get returns None for missing or deleted keys rather than raising an exceptionbitcask-crc32-raises-corruption-error — Reading a record whose payload doesn't match its CRC32 header raises CorruptionError, not a silent wrong valuebitcask-partial-write-silent-discard — On recovery, records truncated mid-write (incomplete payload) are silently discarded without raising errors or appearing in the indexbitcask-compaction-preserves-live-data — Compaction removes stale and tombstoned entries but every live key-value pair survives with its correct latest value