Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

2 Answers 2

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.

share|improve this answer
    
I'd go with your first suggestion: soft-delete on the server with an "IsDeleted" flag. The state of that flag can be sent to clients as part of the delta. –  Ant Jan 22 '13 at 20:55

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.

share|improve this answer
    
For efficiency, as a precursor to the operation described here, the client can also take a checksum of all of its primary keys and send it to the server. The server can then also generate a checksum of all its primary keys. If the checksums match, the server doesn't have to send anything back. –  AbuZubair Jan 22 '13 at 23:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.