to be clear, the original solution does not answer the question, it tries to relay on sqlite specifics, where specifics are beyond the sqlite small world. you must read back the first request to understand.
On Tue, Jul 15, 2014 at 1:10 PM, mm.w <0xcafef...@gmail.com> wrote: > 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
