ATTACHMENT

Unlike documents, ATTACHMENTS store data outside of the Ditto store running locally in the end-user environment and must be explicitly fetched to sync across distributed peers.

​

Merge Strategy: Last-Write-Wins

The REGISTER and the ATTACHMENT type follow the last-write-wins principle to determine the value that ultimately takes precedence and merges across distributed peers. With this approach, each peer seeing the change will sequence it in the same order as every other peer, resulting in the same single value.

For example, one flight attendant updates a customer’s seat number to 6 and another to seat 9. When the two conflicting versions merge, the edit with the highest timestamp wins.

Put another way, by enforcing the last-write-wins merge strategy, for events A and B, where B is a result of A, event A always occurs before B.

Described as unsurprising and meaningful, the last-write-wins strategy means that, rather than arbitrarily resolving all conflicting changes to some predefined value, the value that results and propagates across peers as the single source of truth both reflects the actual end-user input and the update made by the last writer.

​

Ensuring Uninterrupted Fetching

Maintain a strong reference to attachmentFetcher for the entirety of the asynchronous fetch operation by following these guidelines:

• Preserve the attachmentFetcher as a globally accessible instance
• Prevent the fetch operation from silently aborting

​

Creating and Fetching Attachments

The following snippet demonstrates a use case for leveraging the ATTACHMENT, as well as the step-by-step process for creating and fetching the ATTACHMENT:

The following snippet demonstrates creating, associating, and fetching an ATTACHMENT.

1. Define a collection named 'foo'.
2. Using Base64-encoded image data and metadata, create an attachment object.
3. INSERT a document with an attachment in the collection.
4. Later, retrieve the document by _id and fetch the attachment using an attachmentFetcher.