On 12 Oct 2012, at 10:23pm, Nico Williams <n...@cryptonector.com> wrote:
> Here's some more examples of where delayed-D ACKs would be nice: > distributed services. These are really just a variant of my earlier > UI example, but still: a server might respond with an ACK as soon as a > transaction completes with ACI and again when D is achieved, thus > allowing different clients to choose when to demand D independently of > each other. I think I understand what you're asking for, but I see no point in being informed about D, because I can't see anything useful a program can do if the transaction gets marked 'complete' but D doesn't succeed. Either you see D as being part of a transaction, or you don't. By all means, use a PRAGMA to day whether you do need D or not. SQLite already has a dozen ways to do this (though it is very puzzling to try to work out what combination of PRAGMAs to use under your conditions). But report D (or ignore D) as part of the result of 'COMMIT'. Don't make an extra status for "committed but not durable'. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
