Struct logins::LoginsSyncEngine

pub struct LoginsSyncEngine {
    pub store: Arc<LoginStore>,
    pub scope: SqlInterruptScope,
    pub staged: RefCell<Vec<IncomingBso>>,
    /* private fields */
}

Fields

store: Arc<LoginStore>

scope: SqlInterruptScope

staged: RefCell<Vec<IncomingBso>>

Implementations

impl LoginsSyncEngine

pub fn new(store: Arc<LoginStore>) -> Result<Self>

pub fn set_global_state(&self, state: &Option<String>) -> Result<()>

pub fn get_global_state(&self) -> Result<Option<String>>

pub fn do_reset(&self, assoc: &EngineSyncAssociation) -> Result<()>

Trait Implementations

impl SyncEngine for LoginsSyncEngine

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

fn set_local_encryption_key(&mut self, key: &str) -> Result<()>

Tells the engine what the local encryption key is for the data managed by the engine. This is only used by collections that store data encrypted locally and is unrelated to the encryption used by Sync. The intent is that for such collections, this key can be used to decrypt local data before it is re-encrypted by Sync and sent to the storage servers, and similarly, data from the storage servers will be decrypted by Sync, then encrypted by the local encryption key before being added to the local database.

fn stage_incoming( &self, inbound: Vec<IncomingBso>, _telem: &mut Engine ) -> Result<()>

Stage some incoming records. This might be called multiple times in the same sync if we fetch the incoming records in batches.

fn apply( &self, timestamp: ServerTimestamp, telem: &mut Engine ) -> Result<Vec<OutgoingBso>>

Apply the staged records, returning outgoing records. Ideally we would adjust this model to better support batching of outgoing records without needing to keep them all in memory (ie, an iterator or similar?)

fn set_uploaded( &self, new_timestamp: ServerTimestamp, ids: Vec<Guid> ) -> Result<()>

Indicates that the given record IDs were uploaded successfully to the server. This may be called multiple times per sync, once for each batch. Batching is determined dynamically based on payload sizes and counts via the server’s advertised limits.

fn get_collection_request( &self, server_timestamp: ServerTimestamp ) -> Result<Option<CollectionRequest>>

The engine is responsible for building a single 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. It can return None if the server timestamp has not advanced since the last sync. This could even later be extended to handle “backfills”, and we might end up wanting one engine to use multiple collections (eg, as a “foreign key” via guid), etc.

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

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

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

Reset the engine (and associated store) without wiping local data, ready for a “first sync”. assoc defines how this store is to be associated with sync.

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

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

fn sync_finished(&self) -> Result<(), Error>

Called once the sync is finished. Not currently called if uploads fail (which seems sad, but the other batching confusion there needs sorting out first). Many engines will have nothing to do here, as most “post upload” work should be done in set_uploaded()

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

Wipes the engine’s data This is typically triggered by a client command, which at the time of writing, only supported wiping bookmarks.