Repository navigation
Investigate usage of the remote field for vault metadata optimisation #309
Description
Activity
Properties like this can be read from the DB once at the beginning and then cached as an in-memory property for the lifetime of the object.
This is mainly because this doesn't change. If it did change, managing cache coherency becomes a problem. So it's usually better to just leave it in the DB as an SoT and read from it each time when needed. For example see how we have to deal with node id changes.
However DB reads is not a significant cost here. First we make it work (correct), then we can make it fast(er).
So I think majority (all?) of vault metadata should be kept in the DB for now and we can figure out how best to optimise later.
Specification
VaultInternalcurrently has aremoteboolean that indicates whether the vault has been cloned from some other node (i.e. it has an initial remote vault that it has been cloned from). This is also currently an indicator of whether a vault is immutable: cloned vaults are immutable. Previously, this information was stored solely in the metadata database, so any attempted commit to the vault would need to perform a database read to ensure that the vault was mutable.There was previously some discussion on expanding this
remoteboolean to store some additional vault metadata for other optimisation purposes. We should keep this in mind for potential expansions toVaultInternal.Additional context
remotefield (and some other potential parameters for it): No longer preserve vault ID oncloneVault#253 (comment)remotefield is only a boolean now, and suggestions for how/when it could be expanded upon: Introducing vault sharing and the restrictions of pulling and cloning with vault permissions #266 (comment)Tasks