morality good question, wrong solution from the op + wrong solution gain of simon to endorse the bad design, so then when you are serious you roll-back to the entry point not the broken branch.
On Tue, Jul 15, 2014 at 1:12 PM, mm.w <0xcafef...@gmail.com> wrote: > 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
