Scribd
Upload
119 views

Data Synchronization: or As I Don't Like To Call It

The document discusses approaches for synchronizing data between a server and multiple clients to reduce network traffic and requests by only transferring changed data. It proposes a per-item synchronization approach where client and server models each have a UUID, created/modified dates, and is_deleted flag to determine which objects are new, changed, or deleted between clients and server. A step-by-step process is outlined to handle objects only on the client, only on the server, or on both by comparing modification dates and syncing or deleting appropriately.

Uploaded by

Luis Rei
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
119 views

Data Synchronization: or As I Don't Like To Call It

The document discusses approaches for synchronizing data between a server and multiple clients to reduce network traffic and requests by only transferring changed data. It proposes a per-item synchronization approach where client and server models each have a UUID, created/modified dates, and is_deleted flag to determine which objects are new, changed, or deleted between clients and server. A step-by-step process is outlined to handle objects only on the client, only on the server, or on both by comparing modification dates and syncing or deleting appropriately.

Uploaded by

Luis Rei
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

Data Synchronization

or as I dont like to call it

the set reconciliation problem

Core Data vs Server Database

1 Server + Multiple Clients

Requirements
Handle multiple clients: iOS, Web, Desktop... Reduce trafc faster sync mobile trafc is expensive AND extra slow only transfer stuff you have to transfer Reduce the number of requests making multiple requests has a signicant overhead

PER-ITEM SYNC
Client Model
... your stuff ... UUID created modied last_sync is_deleted

Server Model
... your stuff ... UUID created modied is_deleted

metadata

If you need to merge, use per-attribute modication date

Creating GUIDs
CFUUIDRef uuid = CFUUIDCreate(kCFAllocatorDefault); CFUUIDCreateString(kCFAllocatorDefault,uuid);

Probability of Clash
n = 70,368,744,177,664 = 246 => 0.0000000004 (4 1010)
annual risk of being hit by a meteorite (est.) = 0.00000000006 (6 1011)

Step 0: Preparation
Request object metadata from server Request only after earliest last_sync Sort it into: Objects only in client Objects only in server Objects in client & server

Step 1: Objects Only in Client

if !o.is_deleted send o to server else delete o from client

UPDATE CLIENT.O.LAST_SYNC

Step 2: Objects Only in Server

if !o.is_deleted copy o to client

UPDATE CLIENT.O.LAST_SYNC

Step 3: Objects in Client & Server

if client.o.modified > server.o.modified { if client.o.is_deleted { server.o.is_deleted = YES delete o from client } else send client.o to server }

UPDATE CLIENT.O.LAST_SYNC

if client.o.modified < server.o.modified { if server.o.is_deleted delete o from client else copy server.o to client } if client.o.modified == server.o.modified

UPDATE CLIENT.O.LAST_SYNC

our conict resolution strategy is based on always choosing the last modied we could use last_sync to detect conicts present conicts to user? user per-attribute modied date to resolve automatically?

You might also like