# My parity-db branches

List and summary of my favorites parity-db branches. All are in my repo (github.com/cheme/parity-db).
I added [Y] when I think this could be its own discussion in github. [y] when maybe.

These are mostly not needed branch that test some stuff. So this Md is here to keep trace of them in case someone look in similar directions.

- btree_file2: some initial btree code, it uses in memory node which is not usefull, but more interesting it writes nodes in their own file: this was remove to write nodes as value. If at some point we need better perf, using file for nodes like in this branch is an easy performance improvement.

- radix1, radix1-merkle, radix1-with-hash [Y]: In those branch I did test replacing btree by a radix trie structure for indexing and attaching hash to get a rough idea of what could be the performance improvment for storing state trie.
IIRC the write is similar, the read is better.
The radix trie structure is implemented in a crate, the crate was first written for in memory only use case (prefix filter for statemachine access in some branch) and did grow too complex.
Still having a flexible radix trie impl is good since we need it for commit overlay, and I find the backend change to be easier when using this kind of structure.
Still the crate miss: caching node, experiment on concurrent access. More importantly caching/storing/extracting merkle proof.

- file_mmap2 [y]: a branch where I can switch from mmap to file easilly. It is almost ok (had to get awfull api to keep mmap perf), but when using mmap on value table, I got issue with growing file and some failure.

- file_mmap2_log: nice branch, that keep log data in memory and can skip read of log when writing to db. Would need removal of file_mmap2 content, and there is some debugging to do (broken at this point).

- local_storage [Y]: allow different subcollection by storing root of btree in a collection.
I am experimenting with a rc model on nodes that I recently found useless in substrate case (only good if no canonical chain), and rather costly (would need to finish impl and bench).
Every node got an Rc that is shared by all it's children. When a children got non null rc it adds to its parents rc.
The bad is every change to a node change all its parent node (which is node bad if we consider merkel usecase). The worst is every changed node need to add 1 to the rc of its shared children.
So interesting would be to change it to a substrate like design, call it canonicalized local storage. Here we store all storage creation tree (fork of block): a subcollection head then contains : btree root, child first sibling head, next sibling head, add journal, remove journal. We can only change head, pruning apply remove journal (and only allowed if no sibling), revert head revert add journal. So basically something similar to substrate client at db level, main point is journal contains u64 not full keys and could apply it to cover offchain storage usecase as it is key value db not merkle trie storage.

# collecting some ideas for parity-db

- fifo storage (I did a branch for it in the past)
- attached file support (big content support (a file store (got some xp with such system in my past dev life)))
- graph db (more for fun as I don't have a viable merkle scheme)
- iterator record id per columnn
- compile to browser wasm (future based single thread seq of the current threads), with file api (chrome) or indexed db (need async flushing...). I recently realize it is quiet achievable and th wal would have solve the db issue for substrate in browser.
-