From 236aca3befee483e15fc95187e0e222f708b4888 Mon Sep 17 00:00:00 2001 From: Peter Cai Date: Sat, 22 Feb 2020 18:51:06 +0800 Subject: [PATCH] api: items/sync: we don't produce uuid_conflict `uuid_conflict` only exists because the official implementation uses `uuid` as the primary key for their database, while in ours we use an internal ID and then use (uuid, user) tuple to fetch items. i.e. in our implementation, user A and B can have items that have the same UUID. --- src/api.rs | 26 +++++++++++--------------- 1 file changed, 11 insertions(+), 15 deletions(-) diff --git a/src/api.rs b/src/api.rs index 10a8d88..f0e8f97 100644 --- a/src/api.rs +++ b/src/api.rs @@ -273,21 +273,17 @@ fn items_sync( }); // Convert conflicts into the format our client wants - resp.conflicts = items_conflicted.into_iter().map(|(client_item, server_item)| { - // We assume enc_item_key "identifies" an "item" - if client_item.enc_item_key == server_item.enc_item_key { - SyncConflict { - conf_type: "sync_conflict".to_string(), - server_item: Some(server_item), - unsaved_item: None - } - } else { - // A UUID conflict (unlikely) - SyncConflict { - conf_type: "uuid_conflict".to_string(), - server_item: None, - unsaved_item: Some(client_item) - } + resp.conflicts = items_conflicted.into_iter().map(|(_client_item, server_item)| { + // Our implementation never produces `uuid_conflict` + // because the primary key of the `items` table is an internal ID + // and we retrieve content based on (user, uuid) tuple, not just uuid. + // The whole point of having `uuid_conflict` in their official impl + // is because they use `uuid` as the primary key, so two items + // on the same server cannot share the same uuid + SyncConflict { + conf_type: "sync_conflict".to_string(), + server_item: Some(server_item), + unsaved_item: None } }).collect();