Skip to content
This repository has been archived by the owner on Apr 11, 2023. It is now read-only.

Correct handling of fetch's merge and add options #57

Open
nilbus opened this issue Oct 21, 2013 · 2 comments
Open

Correct handling of fetch's merge and add options #57

nilbus opened this issue Oct 21, 2013 · 2 comments

Comments

@nilbus
Copy link
Owner

nilbus commented Oct 21, 2013

Right now, localsync create does some things differently depending on the add and merge options. Should it be? Localsync should probably emulate/mirror the server response, and not care what options are passed to fetch and subsequently set.

Often when using add: true or merge: true with fetch, you're dealing with an API endpoint that does not return a full result set.

@nilbus nilbus added this to the 2.0 milestone Jul 7, 2014
@nilbus nilbus modified the milestone: 2.0 May 3, 2015
@luke83
Copy link
Contributor

luke83 commented Feb 6, 2016

I have sync scenarios like this:
A) client contact the server via API, looking for updates since last call;
B) user works on client, locally, later saves data via API on server;
C) in next call to API from any client ONLY new data since last call will be downloaded.

From any client:

  1. By first call client get all records from server (~7000 recs)
  2. By second call client get all records modified, added, deleted since 1 (# recs << 7000)

The problem
With dualStorage the localStorage saves only records in call 2 - clearing all data from call 1, is there a way to merge partial set in the second call with the - already saved locally - first big set?

PS: I think this is related to #90

Thanks for your work and time!

@nilbus
Copy link
Owner Author

nilbus commented Feb 7, 2016

I don't think this library has a good solution for this right now, but I'm open to ideas.

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

No branches or pull requests

2 participants