Home/ Questions/Q 7217903
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T21:24:45+00:00

I’m setting up a basic sync service for an iPad application I’m developing. The

  • 0

I’m setting up a basic sync service for an iPad application I’m developing. The goal is to have data consistent throughout several instances of the iPad app, as well as having a read-only version of the data on the web, hence rolling a custom solution.

The current flow is this:

  • Each entity has a ‘created’, ‘modified’ and ‘UUID’ field which are automatically updated by Core Data
  • On sync, each entity with a created or modified date after the last sync date is serialised into JSON and sent to the server
  • The server persists any changes to a MySQL database using the client-generated UUIDs as PKs (if there’s a conflict, it just uses the most recently modified entity as the ‘true’ version, nothing fancy there) and sends back any updated entities to the client
  • The client then merges these changes back into its Core Data DB

This all seems to be working fine. My problem is how to track deleted objects using this method? I’m guessing I can add a ‘deleted’ flag to each entity and set this whenever a client deletes something, I can then push that change to the server with the rest of the sync data. Once the sync is complete then the client can actually delete these entities. My questions are:

  • Can I override Core Data’s delete methods to automatically set this flag?
  • Will this require keeping all deleted entities indefinitely on the server? We’ll have no way of knowing when every client has synced and actually deleted each entity (I’m not currently tracking client instances)
  • Is there a better way of doing this?
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    How about you keep a delta history table with UUID and created/updated/deleted field, maybe with a revision number for each update? So you keep a small check list of changes since your last successful sync.

    That way, if you delete an object you could add an entry in the delta history table with the deleted UUID and mark it deleted. Same with created and updated objects, you only need to check the delta table to see what items you the server needs to delete, update, create, etc. You could even store every revision on the server to support rolling back to a previous version in the future if you feel like it.

    I think a revision number is better than relying on client’s clock that could potentially be changed manually.

    You could use NSManagedObjectContext’s insertedObjects, updatedObjects, deletedObjects methods to create the delta objects before every save procedure 🙂

    My 2 cents

    • 0