Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Acknowledgements support #2013

Closed
joy4eg opened this issue Jun 9, 2016 · 4 comments
Closed

Acknowledgements support #2013

joy4eg opened this issue Jun 9, 2016 · 4 comments

Comments

@joy4eg
Copy link
Contributor

joy4eg commented Jun 9, 2016

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.

@joy4eg joy4eg changed the title acknowledges support Acknowledgements support Jun 9, 2016
@drew-gross
Copy link
Contributor

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
Copy link
Contributor Author

joy4eg commented Jun 9, 2016

The client would think the object has been saved, but really the server discarded it.

Yep, it's true ...

Another, but much difficult way, is to add ability to generate objectId on 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
Copy link
Contributor

That approach would have it's own issues. It's essentially what you've done with your localObjectId which 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
Copy link
Contributor

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:

  • node version
  • npm version
  • parse-server version
  • any relevant logs (VERBOSE=1 will enable verbose logging)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants