2 unstable releases

0.2.0 Nov 25, 2023
0.1.0 Mar 1, 2023

#792 in Data structures

Download history 1/week @ 2024-01-11 2/week @ 2024-01-18 37/week @ 2024-02-08 38/week @ 2024-02-15 40/week @ 2024-02-22 34/week @ 2024-02-29 47/week @ 2024-03-07 24/week @ 2024-03-14 19/week @ 2024-03-21 31/week @ 2024-03-28

121 downloads per month
Used in 5 crates

MIT license

27KB
465 lines

yrs-kvstore

yrs-kvstore is a generic library that allows to quickly implement Yrs specific document operations over any kind of persistent key-value store i.e. LMDB or RocksDB. In order to do so, persistent unit of transaction should define set of basic operations via KVStore trait implementation. Once this is done it can implement DocOps. Latter offers a set of useful operations like document metadata management options, document and update merging etc. They are implemented automatically as long struct has correctly implemented KVStore.


lib.rs:

yrs-kvstore is a generic library that allows to quickly implement Yrs specific document operations over any kind of persistent key-value store i.e. LMDB or RocksDB.

In order to do so, persistent unit of transaction should define set of basic operations via [KVStore] trait implementation. Once this is done it can implement [DocOps]. Latter offers a set of useful operations like document metadata management options, document and update merging etc. They are implemented automatically as long struct has correctly implemented [KVStore].

Internal representation

yrs-kvstore operates around few key spaces. All keys inserted via [DocOps] are prefixed with [V1] constant. Later on the key space is further divided into:

  • [KEYSPACE_OID] used for object ID (OID) index mapping. Whenever the new document is being inserted, a new OID number is generated for it. While document names can be any kind of strings OIDs are guaranteed to have constant size. Internally all of the document contents are referred to via their OID identifiers.
  • [KEYSPACE_DOC] used to store document state, its state vector, corresponding series of updates and metadata. Document state and state vector may not represent full system knowledge about the document, as they don't reflect information inside document updates. Updates can be stored separately to avoid big document binary read/parse/merge/store cycles of every update. It's a good idea to insert updates as they come and every once in a while call DocOps::flush_doc or DocOps::flush_doc_with to merge them into document state itself.

The variants and schemas of byte keys in use could be summarized as:

00{doc_name:N}0      - OID key pattern
01{oid:4}0           - document key pattern
01{oid:4}1           - state vector key pattern
01{oid:4}2{seqNr:4}0 - document update key pattern
01{oid:4}3{name:M}0  - document meta key pattern

Dependencies

~2.5–3.5MB
~77K SLoC