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:
parent
09b2f945d2
commit
236aca3bef
18
src/api.rs
18
src/api.rs
|
@ -273,22 +273,18 @@ fn items_sync(
|
||||||
});
|
});
|
||||||
|
|
||||||
// Convert conflicts into the format our client wants
|
// Convert conflicts into the format our client wants
|
||||||
resp.conflicts = items_conflicted.into_iter().map(|(client_item, server_item)| {
|
resp.conflicts = items_conflicted.into_iter().map(|(_client_item, server_item)| {
|
||||||
// We assume enc_item_key "identifies" an "item"
|
// Our implementation never produces `uuid_conflict`
|
||||||
if client_item.enc_item_key == server_item.enc_item_key {
|
// 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 {
|
SyncConflict {
|
||||||
conf_type: "sync_conflict".to_string(),
|
conf_type: "sync_conflict".to_string(),
|
||||||
server_item: Some(server_item),
|
server_item: Some(server_item),
|
||||||
unsaved_item: None
|
unsaved_item: None
|
||||||
}
|
}
|
||||||
} else {
|
|
||||||
// A UUID conflict (unlikely)
|
|
||||||
SyncConflict {
|
|
||||||
conf_type: "uuid_conflict".to_string(),
|
|
||||||
server_item: None,
|
|
||||||
unsaved_item: Some(client_item)
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}).collect();
|
}).collect();
|
||||||
|
|
||||||
// Then, update all items sent by client
|
// Then, update all items sent by client
|
||||||
|
|
Loading…
Reference in a new issue