forgot if != commit again or restore if local unusable (lossy scenario)
On Tue, Jul 15, 2014 at 7:01 AM, mm.w <[email protected]> wrote: > yes indeed the "journal tweaking" would work solely for this special file > case, comparing local and remote that's how for instance git works like > many other sync software, I don't know the API but is the box thing notify > you "on start transaction" then "on close", if not it sucks ? > > > On Tue, Jul 15, 2014 at 6:53 AM, mm.w <[email protected]> wrote: > >> ok sorry, I did not red all thru, may you simply sha1 local and remote ? >> if != commit again >> >> >> On Tue, Jul 15, 2014 at 12:49 AM, Simon Slavin <[email protected]> >> wrote: >> >>> >>> On 15 Jul 2014, at 2:20am, William Drago <[email protected]> >>> wrote: >>> >>> > The software doesn't crash on its own; I'm forcing it to crash with a >>> divide-by-zero for test purposes. This doesn't happen in actual use and >>> there's no reason other than a power failure for a transaction to not >>> commit successfully. But that doesn't mean I shouldn't handle a failed >>> transaction if it ever does happen. >>> >>> If all you're trying to do is spot crashes then you don't have to >>> implement your own semaphore system or locking system. Use >>> >>> PRAGMA journal_mode = DELETE >>> >>> which is the default. Then you know that if a journal file exists, a >>> process is in the middle of a transaction, or a process which in the middle >>> of a transaction crashed. >>> >>> All you need to do is check to see if a file exists with the name of the >>> journal file. Presumably you'd be wanting to do this when your application >>> starts up, before it opens the database. >>> >>> Simon. >>> _______________________________________________ >>> sqlite-users mailing list >>> [email protected] >>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >>> >> >> > _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
