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.
This commit is contained in:
Peter Cai 2020-02-22 18:51:06 +08:00
parent 09b2f945d2
commit 236aca3bef
No known key found for this signature in database
GPG Key ID: 71F5FB4E4F3FD54F
1 changed files with 11 additions and 15 deletions

View File

@ -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();