yes that's exactly what I said thank you to confirm my dear 8) " If the pipe dies halfway then the app would know it" sorry LOL
On Tue, Jul 15, 2014 at 12:13 PM, RSmith <rsm...@rsweb.co.za> wrote: > > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
