Benjamin Bouvier
c64d3b4b7a
This adds a new `StoreTransaction` type, that wraps a `StoreCache` and a `Store`. The idea is that it will allow write access to the `Store` (and maintains the cache at the same time), while the `Store::cache` method will only give read-only access to the store's content. Another new data type is introduced, `PendingChanges`, that reflects `Changes` but for fields that are properly maintained in the `StoreCache` and that one can write in the `StoreTransaction`. In the future, it wouldn't be possible to use `save_pending_changes` from the outside of a `StoreTransaction` context. The layering is the following: - `Store` wraps the `DynCryptoStore`, contains a reference to a `StoreCache`. - When read-only access is sufficient, one can get a handle to the cache with `Store::cache()`. - When a write happens, then one can create a `StoreTransaction` (later, only one at a time will be allowed, by putting the `StoreCache` behind a `RwLock`; this has been deferred to not make the PR grow too much). - Any field in the `StoreCache` will get a method to get a reference to the cached thing: it will either load from the DB if not cached, or return the previously cached value. - Any field that can be written to will get a method to get a mutable reference in the `StoreTransaction`: it will either load from the cache into a `PendingChanges` scratch pad, or return the scratchpad temporary value. - When a `StoreTransaction::commit()` happens, fields are backpropagated into the DB *and* the cache. Then, this `StoreTransaction` is used to update a `ReadOnlyAccount` in multiple places (and usage of `ReadOnlyAccount` is minimized so as not to require a transaction or cache function call as much as possible). With this, the read-only account only exists transiently, and it's only stored long-term in the cache. Followup PRs include: - making the `ReadOnlyAccount` not cloneable - remove inner mutability from the `ReadOnlyAccount` - add a `RwLock` on the `StoreTransaction` Part of https://github.com/matrix-org/matrix-rust-sdk/issues/2624 + https://github.com/matrix-org/matrix-rust-sdk/issues/2000. --- * crypto: Replace some uses of `ReadOnlyAccount` with `StaticAccountData` and identify tests * crypto: introduce `StoreTransaction` to modify a `ReadOnlyAccount` * crypto: introduce `save_pending_changes`, aka `save_changes` v2 * crypto: Start using `StoreTransaction`s to save the account, get rid of `Store::save_account` + `Account::save` * crypto: use `StoreTransaction` to save an account in `keys_for_upload` * crypto: use `StoreTransaction` and the cache in more places * crypto: remove `Account` from the `Changes` \o/ * crypto: remove last (test-only) callers of `Store::account()` * crypto: move `ReadOnlyAccount` inside the cache only * crypto: use `ReadOnlyAccount` and `Account` in fewer places whenever we can use `StaticAccountData` in place. * crypto: make tests rely less on OlmMachine * crypto: Don't put the `ReadOnlyAccount` behind a RwLock just yet + clippy
Matrix Rust SDK bindings
In this directory, one can find bindings to the Rust SDK that are maintained by the owners of the Matrix Rust SDK project.
appleormatrix-rust-components-swift, Swift bindings of thematrix-sdkcrate viamatrix-sdk-ffi,matrix-sdk-crypto-ffi, UniFFI (Kotlin, Swift, Python, Ruby) bindings of thematrix-sdk-cryptocrate,matrix-sdk-ffi, UniFFI bindings of thematrix-sdkcrate.
There are also external bindings in other repositories:
matrix-sdk-crypto-js, JavaScript bindings of thematrix-sdk-cryptocrate,matrix-sdk-crypto-nodejs, Node.js bindings of thematrix-sdk-cryptocrate
Contributing
To contribute read this guide.