Module test_db

Structs

DBLocked

The self-referencing struct.

TestDB

An interface to a btree map backed sally database. This is mainly intended for tests and performing benchmark comparisons

TestDBIter

The self-referencing struct.

TestDBIterAsyncBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call build() to construct the actual struct. The fields of this struct should be used as follows:

TestDBIterAsyncSendBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call build() to construct the actual struct. The fields of this struct should be used as follows:

TestDBIterAsyncSendTryBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call try_build() or try_build_or_recover() to construct the actual struct. The fields of this struct should be used as follows:

TestDBIterAsyncTryBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call try_build() or try_build_or_recover() to construct the actual struct. The fields of this struct should be used as follows:

TestDBIterBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call build() to construct the actual struct. The fields of this struct should be used as follows:

TestDBIterTryBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call try_build() or try_build_or_recover() to construct the actual struct. The fields of this struct should be used as follows:

TestDBKeys

The self-referencing struct.

TestDBKeysAsyncBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call build() to construct the actual struct. The fields of this struct should be used as follows:

TestDBKeysAsyncSendBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call build() to construct the actual struct. The fields of this struct should be used as follows:

TestDBKeysAsyncSendTryBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call try_build() or try_build_or_recover() to construct the actual struct. The fields of this struct should be used as follows:

TestDBKeysAsyncTryBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call try_build() or try_build_or_recover() to construct the actual struct. The fields of this struct should be used as follows:

TestDBKeysBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call build() to construct the actual struct. The fields of this struct should be used as follows:

TestDBKeysTryBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call try_build() or try_build_or_recover() to construct the actual struct. The fields of this struct should be used as follows:

TestDBRevIter

An iterator with a reverted direction to the original. The RevIter is hosting an iteration which is consuming in the opposing direction. It’s not possible to do further manipulation (ex re-reverse) to the iterator.

TestDBValues

The self-referencing struct.

TestDBValuesAsyncBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call build() to construct the actual struct. The fields of this struct should be used as follows:

TestDBValuesAsyncSendBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call build() to construct the actual struct. The fields of this struct should be used as follows:

TestDBValuesAsyncSendTryBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call try_build() or try_build_or_recover() to construct the actual struct. The fields of this struct should be used as follows:

TestDBValuesAsyncTryBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call try_build() or try_build_or_recover() to construct the actual struct. The fields of this struct should be used as follows:

TestDBValuesBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call build() to construct the actual struct. The fields of this struct should be used as follows:

TestDBValuesTryBuilder

A more verbose but stable way to construct self-referencing structs. It is comparable to using StructName { field1: value1, field2: value2 } rather than StructName::new(value1, value2). This has the dual benefit of making your code both easier to refactor and more readable. Call try_build() or try_build_or_recover() to construct the actual struct. The fields of this struct should be used as follows:

TestDBWriteBatch

Enums

WriteBatchOp

Type Aliases

DeleteBatchPayload

DeleteRangePayload

InsertBatchPayload