Add function for updating objects to BaseClient

[raucao]

The app we're working on right now saves different parts of an object from different places. It would be extremely convenient to have a function on the BaseClient that supports updating single properties on existing objects by wrapping storeObject and getObject in one convenient helper function.

API could look like this e.g.:

client.updateObject(path, {keyToUpdateOne: 'foo', keyToUpdateTwo: 'bar'});

The function would then fetch the object using getObject, update only the keys from the second argument and validate and store again via storeObject.

It's actually quite simple, so if someone wants to take a stab at this, go ahead! Don't be afraid of the test suite (if that's a reason not to try), we can help you with that later. ;)

[michielbdejong]

I don't agree this would be easy, since getObject is itself asynchronous, you would have to put a lock/semaphore on the object. Introducing a new in memory structure that keeps track of which items are currently being updated doesn't sound easy to me.

I would advise you to use a SyncedVar instead.

[raucao]

Not sure I understand. Why do you have to put a lock on it, when you can update it as soon as getObject's promise resolves? The idea was that it's just a helper so you don't have to do that manually. There might be a disclaimer needed in the docs for certain scenarios, but I thought in essence it should be very similar to just using storeObject on the same object multiple times in a row, no?

[raucao]

@michielbdejong Any insight on my question?

[michielbdejong]

Right, if you add a disclaimer that this function may result in conflict events, and you should only use it if you either 1) catch and resolve the conflict events, or 2) don't care about conflicts, because you expect people will (almost) never use your app in such a way that multiple devices will be writing to the same object at the same time, and also you make sure the user cannot click edit on the same object so quickly that the requests will overlap, then it's OK, yes.

[raucao]

Thanks.

I don't understand the conflict event part. If you expect people to use the app at the same time from different devices, then this function doesn't make any difference in you having to catch conflicts in any case I believe.

The overlapping requests however seem to be a real issue, as our queue is rather simple and we cannot easily add locking, like you said.

[raucao]

I just realized that we have a very similar issue with #873. If we had a locking mechanism, we could also implement that one without the risk of having new objects stored in a folder that's being deleted.

I still think it's optional, though.