sorry, I did not enter in the specifics of the answer, because it's driven by personal feelings which are off topic and surely misplaced but I will pass on this childish frustrations which are not my concern, bluntly I do not care, if you take that personally it's your problem, deal with it.
thank you. On Tue, Jul 15, 2014 at 1:16 PM, mm.w <0xcafef...@gmail.com> wrote: > 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
