Describe the feature
Right now to change an object the caller must author a json patch to describe the changes they want to make. This turns out to be really difficult to support as there's a lot of ways to describe changes and it gets really complicated to support all of them. Instead of that we would like to provide an API that looks more like this Task<Entry> UpdateEntry(Entry previous, Entry updated), the expected use of this might look like this:
var entry = await api.GetEntry(id);
var original = entry.Copy();
//make changes
entry.LexemeForm["en"] = "test";
//save changes
await api.UpdateEntry(original, entry);
internally we will do a diff between the entries passed in. We will reuse the code we have for keeping a FW and CRDT project in sync.
A downside of this is that an entry object might get quite large and if the user only made a single change they would still pay the cost of passing all the data across the wire.
You could imagine an API where only the changed entry is passed in and the original is fetched from the DB. However this could introduce race conditions where the backend receives changes from somewhere else (a sync or another client), this would then overwrite the changes from the other client as we couldn't detect that the change wasn't made by this client. There may be other ways to handle this, but having the caller pass in what the object looked like before their changes has other benefits.
A benefit of having the caller pass in the original is that they could drop the senses from both objects if they know they didn't make any changes to them, this would be an optimization however.
There could be some ambiguity of the ID of the entry being updated, so it might make sense to require the caller to pass in the id as a 3rd parameter, otherwise we would have to check the ID of both previous and updated and require them to be the same.
Describe the feature Right now to change an object the caller must author a json patch to describe the changes they want to make. This turns out to be really difficult to support as there's a lot of ways to describe changes and it gets really complicated to support all of them. Instead of that we would like to provide an API that looks more like this
Task<Entry> UpdateEntry(Entry previous, Entry updated)
, the expected use of this might look like this:internally we will do a diff between the entries passed in. We will reuse the code we have for keeping a FW and CRDT project in sync. A downside of this is that an entry object might get quite large and if the user only made a single change they would still pay the cost of passing all the data across the wire.
You could imagine an API where only the changed entry is passed in and the original is fetched from the DB. However this could introduce race conditions where the backend receives changes from somewhere else (a sync or another client), this would then overwrite the changes from the other client as we couldn't detect that the change wasn't made by this client. There may be other ways to handle this, but having the caller pass in what the object looked like before their changes has other benefits.
A benefit of having the caller pass in the original is that they could drop the senses from both objects if they know they didn't make any changes to them, this would be an optimization however.
There could be some ambiguity of the ID of the entry being updated, so it might make sense to require the caller to pass in the id as a 3rd parameter, otherwise we would have to check the ID of both
previous
andupdated
and require them to be the same.