Differences

This shows you the differences between two versions of the page.

--- dev:web_api:v3:syncing [2019/03/19 05:37] – [Full-Library Syncing] dstillman
+++ dev:web_api:v3:syncing [2019/05/25 06:54] – [Collection/Tag Deletions and Syncing] dstillman
@@ Line 14: / Line 14: @@
   * A version number for each library
   * A version number and a boolean ''synced'' flag for each syncable object
-  * A flag indicating that a downloaded object could not be processed and should be requested explicitly regardless of its remote version number (optional; see [[#Handling save errors|Handling save errors]] for details)
+  * A list of downloaded objects that could not be processed and should be requested explicitly regardless of their remote version number (optional; see [[#Handling save errors|Handling save errors]] for details)
 ===== Version Numbers =====
@@ Line 328: / Line 328: @@
 Note that multi-object endpoints should always be used for large operations. Using single-object endpoints excessively could result in throttling by the server.
-===== Collection/Tag Deletions and Syncing =====
-A collection or tag deletion will cause all associated items to be updated on the server, and the updated items will be set to the library version returned by the deletion request. This interaction between object types can result in sync conflicts if clients don't take special precautions when performing these actions.
-Clients have two options for performing collection and tag deletions:
-==== Re-upload Items and Delete Collection/Tag ====
-This method is appropriate for clients that sync the entire library.
-When deleting a collection/tag locally, mark previously associated items as changed. Before sending the collection/tag DELETE request, upload the modified items to the server. Once those changes have been uploaded, the DELETE for the collection/tag can be sent. Since the collection/tag on the server will have no associated items, there is no potential for a conflict between local and remote items.
-==== Delete Collection/Tag and Redownload Items ====
-This method is appropriate for clients that will not necessarily have all items associated with the collection/tag locally or that expect to have significantly more limited upload bandwidth.
-When deleting a collection/tag locally, the client should not mark previously associated items as changed to avoid triggering conflicts when the items updated on the server are redownloaded.
-However, a conflict can still occur if an associated item is modified locally in other ways and not synced to the server before the collection/tag deletion is uploaded. When the client tries to pull down the updated remote item after the collection/tag deletion, the local version will be marked as changed, and since the data won't match, the client will need to perform conflict resolution.
-To avoid this, clients can store a pristine copy of the item data (not counting collections and tags) before modifying an item locally. This will allow the client to determine what local and remote changes have been made since the item was last downloaded.
-Then, when a conflict occurs, if the server's item data matches the pristine copy and the server collections/tags match the current local collections/tags, clients can just upload the local item data changes.
-If the server item data doesn't match the pristine copy, the client can attempt to apply both local and remote changes and perform a conflict resolution only if the same field has been modified.
-If the server collections/tags don't match the current local collections/tags, the client will need to either perform conflict resolution or automatically merge the collections and tags, restoring any deleted ones.