Timeline for A simple approach for data synchronisation
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Mar 15 at 7:50 | history | suggested | Stefan Verhagen | CC BY-SA 4.0 |
mostly correction of typos
|
| Mar 14 at 14:56 | review | Suggested edits | |||
| S Mar 15 at 7:50 | |||||
| Aug 3, 2017 at 16:15 | history | edited | Tulains Córdova | CC BY-SA 3.0 |
added 3 characters in body
|
| Dec 16, 2015 at 2:48 | comment | added | User | when I say "do one operation in the database" I mean a set of queries that I submit to the driver together. For example an operation as described that first reads then does multiple updates, everything is a sequence of sql commands which are executed in 1 database access, and transactionally. | |
| Dec 16, 2015 at 2:44 | comment | added | User | @JeffreySweeney could you elaborate a bit more on that (database noob here)? I'm using a framework that works asynchronously but this builds on top of JDBC and MySQL, would it be possible while I'm doing one operation in the database - say read some data, then use this to do several updates - for another thread to execute another operation in the database at the same time? Such that, for example, this also updates the rows from my other transaction and I end with lost updates? Aren't the operations once in the database executed in sequence, that is after complete previous queries finish? | |
| Dec 15, 2015 at 22:34 | comment | added | Tulains Córdova | @JeffreySweeney This are todo-items in a todo list so partial updates are not fatal error. However, every job can be done inside a database transaction so either all operations are committed or none is commited (atomic). You can have atomic transactions in an asynchronous or batch process. | |
| Dec 15, 2015 at 22:00 | comment | added | Jeffrey Sweeney | I'd argue that updating data needs to be synchronous if the data can be partially updated. Otherwise, data integrity cannot be guaranteed. | |
| Dec 15, 2015 at 19:08 | comment | added | User | Mhh interesting. Yeah update overwrites would be unavoidable without a timestamp check. But I think that's ok. Wonder about the performance, my code is already asynchronous (the database access also). But not limited to a single thread. Also, to represent these transactions, a nosql database is probably suitable? Have a lot of items with very different structure. Not sure if it's worth to rewrite my sync instead of trying to improve what I have already. For now +1, I'm curious if there are other approaches. | |
| Dec 15, 2015 at 17:55 | comment | added | Tulains Córdova | @ixxzz The gist of my answer is that by doing it asyncrhonously you take out a lot of complexity. | |
| Dec 15, 2015 at 17:52 | history | edited | Tulains Córdova | CC BY-SA 3.0 |
added 112 characters in body
|
| Dec 15, 2015 at 17:51 | comment | added | Tulains Córdova | Yes, one thread. Overwrites are unavoidable since you cannot prevent a later transaction to overwrite the change you previously made, neither with my approach or yours, although I've seen that Apple just duplicates some entries when there's a conflict, when syncing notes, which is weird since nobody else is syncing my notes. I'll add an edit to the overwrites part. | |
| Dec 15, 2015 at 16:41 | comment | added | User | wow this is entirely different than everything I implemented so far... so serialise all the operations in so to say a queue? I assume there would be only 1 worker thread then? Why do you say overwrites cannot be avoided? (the -1 is not from me btw) | |
| Dec 15, 2015 at 16:33 | history | answered | Tulains Córdova | CC BY-SA 3.0 |