diff options
author | Ilya Zhuravlev <zhuravlevilya@ya.ru> | 2012-10-23 01:18:44 +0400 |
---|---|---|
committer | Sfan5 <sfan5@live.de> | 2013-09-09 22:50:50 +0200 |
commit | 58841ef12f6cba1bb622353c1fcaa0e3c6fb46c9 (patch) | |
tree | 6012bbb1905231025dff89aa73782a7c38666839 /src/leveldb/TODO | |
parent | 71a8769bb5ded4acb3f9e5a8502bb8af277f824d (diff) | |
download | minetest-58841ef12f6cba1bb622353c1fcaa0e3c6fb46c9.tar.gz minetest-58841ef12f6cba1bb622353c1fcaa0e3c6fb46c9.tar.bz2 minetest-58841ef12f6cba1bb622353c1fcaa0e3c6fb46c9.zip |
Add dummy and LevelDB database backends
Diffstat (limited to 'src/leveldb/TODO')
-rw-r--r-- | src/leveldb/TODO | 14 |
1 files changed, 14 insertions, 0 deletions
diff --git a/src/leveldb/TODO b/src/leveldb/TODO new file mode 100644 index 000000000..e603c0713 --- /dev/null +++ b/src/leveldb/TODO @@ -0,0 +1,14 @@ +ss +- Stats + +db +- Maybe implement DB::BulkDeleteForRange(start_key, end_key) + that would blow away files whose ranges are entirely contained + within [start_key..end_key]? For Chrome, deletion of obsolete + object stores, etc. can be done in the background anyway, so + probably not that important. +- There have been requests for MultiGet. + +After a range is completely deleted, what gets rid of the +corresponding files if we do no future changes to that range. Make +the conditions for triggering compactions fire in more situations? |