Syncing between multiple clients is a very complext task.
Let's not call it syncing, let's call it bashbatch transaction processing.
Let's get rid of "last server update timestamp", let's just every transaction be inserted into a pre-process table with a timestamp generated by the server.
Let's make it asyncronousasynchronous. If data is processed fast enough, users shouldn't notice.
Client generates a job id (hash of userid plus timestamp plus some other randonrandom data), and pushes it to the server.
Server saves the job id in a jobs table and assigns it with a timestamp
Client sends transactions that will be in that job
ITEM ID is client generated using a hash function the same way job id was generated.
A process that runs, say every few seconds gets the more recent pending job, and proceeds to process all transactions.
Transactions that couldn't be done because the ITEM was previously erased are inserted in a rejects table
Current data after transaction is pushed to client including rejections (client data is deleted and new data is inserted, client perceives it as a refresh)
A jobsjob can be transanction-less, meaning it's only a refresh request.
Overwrites cannot be avoided but you can opt to duplicate entries when a conflict arises instead of overwriting the older version of an item.
Syncing between multiple clients is a very complext task.
Let's not call it syncing, let's call it bash transaction processing.
Let's get rid of "last server update timestamp", let's just every transaction be inserted into a pre-process table with a timestamp generated by the server.
Let's make it asyncronous. If data is processed fast enough, users shouldn't notice.
Client generates a job id (hash of userid plus timestamp plus some other randon data), and pushes it to the server.
Server saves the job id in a jobs table and assigns it a timestamp
Client sends transactions that will be in that job
ITEM ID is client generated using a hash function the same way job id was generated.
A process that runs, say every few seconds gets the more recent pending job, and proceeds to process all transactions.
Transactions that couldn't be done because the ITEM was previously erased are inserted in a rejects table
Current data after transaction is pushed to client including rejections (client data is deleted and new data is inserted, client perceives it as a refresh)
A jobs can be transanction-less, meaning it's only a refresh request.
Overwrites cannot be avoided but you can opt to duplicate entries when a conflict arises instead of overwriting the older version of an item.
Syncing between multiple clients is a very complext task.
Let's not call it syncing, let's call it batch transaction processing.
Let's get rid of "last server update timestamp", let's just every transaction be inserted into a pre-process table with a timestamp generated by the server.
Let's make it asynchronous. If data is processed fast enough, users shouldn't notice.
Client generates a job id (hash of userid plus timestamp plus some other random data), and pushes it to the server.
Server saves the job id in a jobs table and assigns it with a timestamp
Client sends transactions that will be in that job
ITEM ID is client generated using a hash function the same way job id was generated.
A process that runs, say every few seconds gets the more recent pending job, and proceeds to process all transactions.
Transactions that couldn't be done because the ITEM was previously erased are inserted in a rejects table
Current data after transaction is pushed to client including rejections (client data is deleted and new data is inserted, client perceives it as a refresh)
A job can be transanction-less, meaning it's only a refresh request.
Overwrites cannot be avoided but you can opt to duplicate entries when a conflict arises instead of overwriting the older version of an item.
Syncing between multiple clients is a very complext task.
Let's not call it syncing, let's call it bash transaction processing.
Let's get rid of "last server update timestamp""last server update timestamp", let's just every transaction be inserted into a pre-process table with a timestamp generated by the server.
Let's make it asyncronous. If data is processed fast enough, users shouldn't notice.
Client generates a job id (hash of userid plus timestamp plus some other randon data), and pushes it to the server.
Server saves the job id in a jobs table and assigns it a timestamp
Client sends transactions that will be in that job
ITEM ID is client generated using a hash function the same way job id was generated.
A process that runs, say every few seconds gets the more recent pending job, and proceeds to process all transactions.
Transactions that couldn't be done because the ITEM was preciouslypreviously erased are inserted in a rejects table
Current data after transaction is pushed to client including rejections (client data is deleted and new data is inserted, client perceives it as a refresh)
A jobs can be transanction-less, meaning it's only a refresh request.
Overwrites cannot be avoided but you can opt to duplicate entries when a conflict arises instead of overwriting the older version of an item.
Syncing between multiple clients is a very complext task.
Let's not call it syncing, let's call it bash transaction processing.
Let's get rid of "last server update timestamp", let's just every transaction be inserted into a pre-process table with a timestamp generated by the server
Let's make it asyncronous. If data is processed fast enough, users shouldn't notice.
Client generates a job id (hash of userid plus timestamp plus some other randon data), and pushes it to the server.
Server saves the job id in a jobs table and assigns it a timestamp
Client sends transactions that will be in that job
ITEM ID is client generated using a hash function the same way job id was generated.
A process that runs, say every few seconds gets the more recent pending job, and proceeds to process all transactions.
Transactions that couldn't be done because the ITEM was preciously erased are inserted in a rejects table
Current data after transaction is pushed to client including rejections (client data is deleted and new data is inserted, client perceives it as a refresh)
A jobs can be transanction-less, meaning it's only a refresh request.
Overwrites cannot be avoided but you can opt to duplicate entries when a conflict arises instead of overwriting the older version of an item.
Syncing between multiple clients is a very complext task.
Let's not call it syncing, let's call it bash transaction processing.
Let's get rid of "last server update timestamp", let's just every transaction be inserted into a pre-process table with a timestamp generated by the server.
Let's make it asyncronous. If data is processed fast enough, users shouldn't notice.
Client generates a job id (hash of userid plus timestamp plus some other randon data), and pushes it to the server.
Server saves the job id in a jobs table and assigns it a timestamp
Client sends transactions that will be in that job
ITEM ID is client generated using a hash function the same way job id was generated.
A process that runs, say every few seconds gets the more recent pending job, and proceeds to process all transactions.
Transactions that couldn't be done because the ITEM was previously erased are inserted in a rejects table
Current data after transaction is pushed to client including rejections (client data is deleted and new data is inserted, client perceives it as a refresh)
A jobs can be transanction-less, meaning it's only a refresh request.
Overwrites cannot be avoided but you can opt to duplicate entries when a conflict arises instead of overwriting the older version of an item.
Syncing between multiple clients is a very complext task.
Let's not call it syncing, let's call it bash transaction processing.
Let's get rid of "last server update timestamp", let's just every transaction be inserted into a pre-process table with a timestamp generated by the server
Let's make it asyncronous. If data is processed fast enough, users shouldn't notice.
Client generates a job id (hash of userid plus timestamp plus some other randon data), and pushes it to the server.
Server saves the job id in a jobs table and assigns it a timestamp
Client sends transactions that will be in that job
ITEM ID is client generated using a hash function the same way job id was generated.
A process that runs, say every few seconds gets the more recent pending job, and proceeds to process all transactions.
Transactions that couldn't be done because the ITEM was preciously erased are inserted in a rejects table
Current data after transaction is pushed to client including rejections (client data is deleted and new data is inserted, client perceives it as a refresh)
A jobs can be transanction-less, meaning it's only a refresh request.
Overwrites cannot be avoided but you can opt to duplicate entries when a conflict arises instead of overwriting the older version of an item.
Syncing between multiple clients is a very complext task.
Let's not call it syncing, let's call it bash transaction processing.
Let's get rid of "last server update timestamp", let's just every transaction be inserted into a pre-process table with a timestamp generated by the server
Let's make it asyncronous. If data is processed fast enough, users shouldn't notice.
Client generates a job id (hash of userid plus timestamp plus some other randon data), and pushes it to the server.
Server saves the job id in a jobs table and assigns it a timestamp
Client sends transactions that will be in that job
ITEM ID is client generated using a hash function the same way job id was generated.
A process that runs, say every few seconds gets the more recent pending job, and proceeds to process all transactions.
Transactions that couldn't be done because the ITEM was preciously erased are inserted in a rejects table
Current data after transaction is pushed to client including rejections (client data is deleted and new data is inserted, client perceives it as a refresh)
A jobs can be transanction-less, meaning it's only a refresh request.
Overwrites cannot be avoided.
Syncing between multiple clients is a very complext task.
Let's not call it syncing, let's call it bash transaction processing.
Let's get rid of "last server update timestamp", let's just every transaction be inserted into a pre-process table with a timestamp generated by the server
Let's make it asyncronous. If data is processed fast enough, users shouldn't notice.
Client generates a job id (hash of userid plus timestamp plus some other randon data), and pushes it to the server.
Server saves the job id in a jobs table and assigns it a timestamp
Client sends transactions that will be in that job
ITEM ID is client generated using a hash function the same way job id was generated.
A process that runs, say every few seconds gets the more recent pending job, and proceeds to process all transactions.
Transactions that couldn't be done because the ITEM was preciously erased are inserted in a rejects table
Current data after transaction is pushed to client including rejections (client data is deleted and new data is inserted, client perceives it as a refresh)
A jobs can be transanction-less, meaning it's only a refresh request.
Overwrites cannot be avoided but you can opt to duplicate entries when a conflict arises instead of overwriting the older version of an item.