Core data syncing (deletion) using a custom REST web service

Question

I need to sync my local core data stack against a server running a persistent data storage underneath the covers. (I've gone through other posts here and on SO on similar topics)

My requirements:

1. One way syncing. Meaning my server is always updated and my clients just merely need to be fed incremental deltas which they feed into their core data stack.

2. The server could arbitrarily insert new records, modify existing ones or even delete them.

I would rather not use RestKit because I can do the work of making queries and updating local state myself. I don't need an extra library to do this.

My solution:

I keep a last updated date (UTC) locally. I send this date to my server periodically and my server responds with the data I need to update or insert, based on a server timestamp for each record.

My problem:

I don't know how to handle deletes.

How would I handle deletes in such a scenario? If I delete the record from the server, how will clients know to delete that record as well.

Thoughts? I can think of a number of complicated ways to do it (e.g. don't really delete the record, or keep track separately of deleted records, etc.), but I'm looking for the simplest.

Answer 1

Your solution is good but as you found, you need to keep the deleted record somewhere to inform the clients.

Another solution is to require that the clients "registers" to your server. Then keep a queue of all changes per client on the server. It consumes more space on the server side but can keep track of all changes and not only the last state of a record.

Answer 2

Although 20c and Ant have both proposed reasonable solutions, I really didn't want to maintain any extra state such as a deleted flag or per-client data. It just becomes too complicated for my taste.

The solution that I'm going to implement for deletion will simply be the following:

1. Client issues a delete request. This request can only be made once update/inserts are up to date.
2. Server responds with the primary key (a 4 byte integer) of every single record. This response is also compressed to save space. For reference, 40k records worth of primary keys compressed is about 20k bytes.
3. Client then does a cross reference and deletes records that have primary keys which the server did not include.

I just wanted to throw this out there is a viable solution as well.