Trait sync15_traits::Store

pub trait Store {
    fn collection_name(&self) -> Cow<'static, str>;
    fn apply_incoming(
        &self, 
        inbound: Vec<IncomingChangeset>, 
        telem: &mut Engine
    ) -> Result<OutgoingChangeset>;
    fn sync_finished(
        &self, 
        new_timestamp: ServerTimestamp, 
        records_synced: Vec<Guid>
    ) -> Result<()>;
    fn get_collection_requests(
        &self, 
        server_timestamp: ServerTimestamp
    ) -> Result<Vec<CollectionRequest>>;
    fn get_sync_assoc(&self) -> Result<StoreSyncAssociation>;
    fn reset(&self, assoc: &StoreSyncAssociation) -> Result<()>;
    fn wipe(&self) -> Result<()>;

    fn prepare_for_sync(
        &self, 
        _get_client_data: &dyn Fn() -> ClientData
    ) -> Result<()> { ... }
}

Low-level store functionality. Stores that need custom reconciliation logic should use this.

Different stores will produce errors of different types. To accommodate this, we force them all to return failure::Error.

Required methods

fn collection_name(&self) -> Cow<'static, str>

fn apply_incoming(
    &self,
    inbound: Vec<IncomingChangeset>,
    telem: &mut Engine
) -> Result<OutgoingChangeset>

inbound is a vector to support the case where get_collection_requests returned multiple requests. The changesets are in the same order as the requests were -- e.g. if vec![req_a, req_b] was returned from get_collection_requests, inbound will have the results from req_a as its first index, and those from req_b as it's second.

fn sync_finished(
    &self,
    new_timestamp: ServerTimestamp,
    records_synced: Vec<Guid>
) -> Result<()>

fn get_collection_requests(
    &self,
    server_timestamp: ServerTimestamp
) -> Result<Vec<CollectionRequest>>

The store is responsible for building the collection request. Engines typically will store a lastModified timestamp and use that to build a request saying "give me full records since that date" - however, other engines might do something fancier. This could even later be extended to handle "backfills" etc

To support more advanced use cases (e.g. remerge), multiple requests can be returned here. The vast majority of engines will just want to return zero or one item in their vector (zero is a valid optimization when the server timestamp is the same as the engine last saw, one when it is not)

Important: In the case when more than one collection is requested, it's assumed the last one is the "canonical" one. (That is, it must be for "this" collection, its timestamp is used to represent the sync, etc).

fn get_sync_assoc(&self) -> Result<StoreSyncAssociation>

Get persisted sync IDs. If they don't match the global state we'll be reset() with the new IDs.

fn reset(&self, assoc: &StoreSyncAssociation) -> Result<()>

Reset the store without wiping local data, ready for a "first sync". assoc defines how this store is to be associated with sync.

fn wipe(&self) -> Result<()>

Loading content...

Provided methods

fn prepare_for_sync(
    &self,
    _get_client_data: &dyn Fn() -> ClientData
) -> Result<()>

Prepares the store for syncing. The tabs store currently uses this to store the current list of clients, which it uses to look up device names and types.

Note that this method is only called by sync_multiple, and only if a command processor is registered. In particular, prepare_for_sync will not be called if the store is synced using sync::synchronize or sync_multiple::sync_multiple. It will be called if the store is synced via the Sync Manager.

TODO(issue #2590): This is pretty cludgey and will be hard to extend for any case other than the tabs case. We should find another way to support tabs...

Loading content...

Implementors

Loading content...