Data Store CRUD

DELETE

This article provides an overview and how-to instructions for deleting documents using the EVICT DQL operation.

Evicting Data



Sample EVICT Query

Swift
Kotlin
JS
Java
C#
C++
Rust
Dart


Evicting Multiple Documents in a Collection

The EVICT operation functions based on a condition, allowing updates to multiple documents simultaneously.

For example, the following snippet, once executed, purges all blue cars stored in the local Ditto store.

Swift
Kotlin
JS
Java
C#
C++
Rust
Dart


Using Evict with Sync Subscriptions

If subscriptions are not properly managed prior to executing evictions, you may inadvertently disrupt the intended state, resulting in inconsistencies and unexpected behavior.

For example, if you have an active subscription for fetching 'blue' cars and you subsequently evict the document with the ID '123456' that matches the replication query, connected peers reinstate it in your local Ditto store. In other words, without modifying the subscription first, peers in the mesh will replicate the evicted document back to the local peer that evicted it.

Therefore we encourage careful management of subscriptions and evictions. To remove documents with active subscriptions, you must first cancel the relevant subscription before calling the EVICT method.

Timing Subscriptions and Evictions



In addition, take a balanced approach when using the Subscribe and Evict methods. Consider the advantages and drawbacks of each method and use them as appropriate for specific needs and requirements.

Key considerations for using Subscription and Eviction methods include:

  • Use Subscribe to sync more data across connected peers in the mesh; however, be mindful of potential increased network usage, which may degrade sync performance.
  • Use Evict to manage local storage capacity and improve performance by routinely purging data stored locally.

Coordinating Evictions



Swift
Kotlin
JS
Java
C#
C++
Rust
Dart


Deleting Attachments

Unlike documents, attachments cannot be explicitly deleted on their own. Instead, you modify the document containing the attachment token referencing it.

Attachment data stored within the Small Peer Ditto store is automatically garbage collected on a 10-minute cadence when no longer referenced. Currently, attachments can only be deleted by way of garbage collection.

The following table provides an overview of the various ways you can indirectly delete attachments:

Approach

Description

UPDATE

Update the document to remove the associated attachment token.

EVICT

Delete the entire document, including the associated attachment token, from the Ditto store.

The storage mechanism Small Peers use to store data, including blob data, depends on the platform:

  • If running in the browser or a server-based system, data is stored in its Random Access Memory (RAM).
  • If running on a mobile device like an iPhone, data is stored on its local filesystem.

Referencing Previously Evicted Documents

Once removed, you can reference the evicted document using the mutatedDocumentIDs method on the result.

Soft-Delete Pattern



Adding a Soft-Delete Flag

To add a soft-delete pattern, set the isArchived field value to true:

Ditto Document


Querying Non-Archived Documents

To query to monitor documents that are NOT archived, establish a live query where isArchived is set to false, and then construct your live query callback.

It's likely that the isArchived field is set lazily (i.e. has no value until it is true), so you can use the coalesce() function to automatically return false if the value is unset. The following code demonstrates searching for documents that are unarchived:

Swift
Kotlin
JS
Java
C#
C++
Rust
Dart


Removing Soft-Delete Flag

To remove the flag and reactivate the document, set the isArchived field to false:

Swift
Kotlin
JS
Java
C#
C++
Rust
Dart


Removing Data from Big Peer

EVICT is not currently available for the Big Peer, although it's in development. To learn more about removing data from your Big Peer instance, see Writing: HTTP (Legacy).

Considerations



Access Frequency and Relevance Considerations

In peer-to-peer system design, there are technical tradeoffs between the amount of data synced across peers and the timeliness of access to synced data:

  • The greater the amount of data synced, the more timely offline read access becomes. That is, database resilience in offline scenarios increases when more documents are being synced across distributed peers.
  • The fewer the number of documents replicated, the less the likelihood that peer devices run out of disk space and experience memory leaks, and the performance of the peer-to-peer mesh network that interconnects them degrades.

For considerations on using the Evict and Subscribe methods, see Timing Subscriptions and Evictions.