to be clear, I am not a social worker but an engineer and never argue when I consider that's a lost cause, if you cannot straight talking 5 minutes in your life... don't ask me to say "bravo", it's not big deal my little ducky when I think the contrary especially on a topic I know from the outside and the inside and all the possible entry point.
thank you for getting back on earth. On Tue, Jul 15, 2014 at 1:27 PM, mm.w <0xcafef...@gmail.com> wrote: > 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
