Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
dev:web_api:v3:syncing [2019/03/19 05:38] – [Sync Properties] dstillman | dev:web_api:v3:syncing [2021/03/24 16:06] – [Handling save errors] dstillman | ||
---|---|---|---|
Line 219: | Line 219: | ||
- Treat the error as fatal and stop the sync without updating the local library version | - Treat the error as fatal and stop the sync without updating the local library version | ||
- | - Add the object key to a list of objects needing to be downloaded later and continue with the sync, updating the local library version at the end as if the sync had succeeded. In a future sync, add objects on this list to the set of objects returned from the '' | + | - Add the object key to a list of objects needing to be downloaded later and continue with the sync, updating the local library version at the end as if the sync had succeeded. In a future sync, add objects on this list to the set of objects returned from the '' |
When processing a set of objects, it may be helpful to maintain a process queue for the sync run and move failing objects to the end of the queue in case they depend on other objects being retrieved. (In many cases, it's possible to sort objects beforehand to avoid such errors, such as by sorting parent collections before subcollections.) If a loop of the process queue completes without any objects being successfully processed, stop the sync. | When processing a set of objects, it may be helpful to maintain a process queue for the sync run and move failing objects to the end of the queue in case they depend on other objects being retrieved. (In many cases, it's possible to sort objects beforehand to avoid such errors, such as by sorting parent collections before subcollections.) If a loop of the process queue completes without any objects being successfully processed, stop the sync. | ||
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. | 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/ | ||
- | |||
- | 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/ | ||
- | |||
- | This method is appropriate for clients that sync the entire library. | ||
- | |||
- | When deleting a collection/ | ||
- | |||
- | ==== Delete Collection/ | ||
- | |||
- | This method is appropriate for clients that will not necessarily have all items associated with the collection/ | ||
- | |||
- | When deleting a collection/ | ||
- | |||
- | 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/ | ||
- | |||
- | 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' | ||
- | |||
- | If the server item data doesn' | ||
- | |||
- | If the server collections/ | ||
- | |||
- | |||