On 2014/07/15 19:06, mm.w wrote:
Simon your design-idea do not reflect any reality, this is weak, there is a lack of experience on the topic and we can feel it.
Strange, I feel nothing of the sort and the only weak thing I can see involves the correlation between the computer and social skill sets you wield. Maybe you had a very different use-case in mind than what is normal for SQLite? - which is of course allowed.
"You won't have anything to commit. If your application really had crashed it wouldn't have any transaction data to commit. If your application had not crashed the transaction would always have worked." nope you can have a partial upload, a broken socket pipe et cetera, and you only assume a version of the file is not already remote and assume that after crash you might be able to recover local anyway.
Partial uploads... broken pipes... these are all networking related issues and has nothing to do with file commitment of any SQLite code. When you make a server-client system which upload a stream or download it, or in any way sends it somewhere or manages synchronicity, it is the responsibility of either the client or the server to commit those databits to disk, not the pipe's responsibility. If the pipe dies halfway then the app would know it, and no amount of half-commits can happen. The only time SQLite engine can "break" a file by not completing a commit is if the program itself crashes or the physical media errors out, just like Simon said - none of which involve programmed-logic solutions. Report error and die - this is the way the Force guides us.
there are two scenario to check: local = remote after any network transaction local = remote after incident: + if not remote, test integrity of local + if remote make sure both are safe + if only remote restore/force sync has you got an interrupt (it happens with box) 1- the network flow could be interrupted no need a power failure for that to happen, it can happen that's you face also the case of undetected broken pipe, that's the reason you need to be notify by the network pooler API you use, 2- the journal tweaking only concern sqlite file and specific to it, then wrong design, make it work for anything using the "common regular" system of hashing/signing local to remote to ensure the integrity of the data, at least that's the only purpose of this discussion how I am sure whatever happen that I have my data in good shape somewhere.
This is establishing whether a file-transfer between some syncing services is successful and current, it has not a single thing to do with SQLite's ability to commit changes to the file or judging the need for roll-back. When SQLite starts the file is either broken or not, end of. This should be checked on a high level and has no bearing on anything to do with SQLite.
_______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
