Repository navigation
Acknowledgements support #2013
Description
Hi,
We using parse-server and parse android SDK for our application.
Sometimes devices with our app loses the Internet connection (poor WiFi signal, or smth else) when request to create new object is running, and usually we get connection timeout error.
But, on server site object was successfully created and stored.
Later when interned connection will restored, we send request again and get objectId on device, AND get first object too.
It is commutation error, and now we have two same object with different objectId on server and on local application.
As workaround, each our object has localObjectId which generates on device, and in beforeSave trigger we remove same objects from database.
What i propose: add support of acknowledges, smth like this:
user ---> server: create new object instance of Foo
server ---> user: done, objectId: 42 (server creates a timer for 'thanks' message)
user --> server: thanks. Now server can safely save new object to database.
With this method we can safely and clearly avoid duplicates objects without overheads.
Comments are welcome.
Activity
[-]acknowledges support[/-][+]Acknowledgements support[/+]drew-gross commentedon Jun 9, 2016
Aside from the huge performance impact this would have, it wouldn't actually solve the problem, because what happens if the "thanks" message gets delayed, and only reaches the server after the timer has expired? The client would think the object has been saved, but really the server discarded it.
joy4eg commentedon Jun 9, 2016
Yep, it's true ...
Another, but much difficult way, is to add ability to generate
objectIdon the device side. I guess is will solve the problem, because with second request our object will updated not created.What do you think about it ?
drew-gross commentedon Jun 9, 2016
That approach would have it's own issues. It's essentially what you've done with your
localObjectIdwhich does work, but doing it within parse would be changing every SDK. It would also mean we can't guarantee that object IDs are distributed evenly, as a malicious client could start sending non-evenly-distributed IDs. Some features we have planned rely on object IDs being evenly distributed, so I don't want to go with that approach.I think keeping your workaround is probably the best approach for now.
flovilmart commentedon Jul 13, 2016
Closing due to lack of activity, please update to latest parse-server version and reopen if the issue persist.
Don't forget to include your current: