On Monday 01 May 2006 16:47, Chris Darroch wrote: > Nick Kew wrote: > > There's rather more than that: after any failed operation within > > a transaction, apr_dbd assumes transaction failure and declines > > to attempt any further ops, without reference to the backend. > > I think perhaps we should remove this logic from all the drivers > entirely. Here's why, and it connects back to my initial notion > of a "forceable commit" option, which I realize now was really > based on an instinct that I'd sometimes want to override the > built-in decision by apr_dbd to cancel my transaction.
Well, postgresql will give us essentially the same logic within its transactions, and I had an idea other databases did similar things. Cheaper for apr_dbd to do it without troubling the backend, and I'd be reluctant to change that, at least as default behaviour. > A simple example from (my) real life would be that I sometimes > want to insert a row and, if a constraint violation occurs, do > something else. If I do that work outside an apr_dbd transaction, > no problem. If I do it inside, though, apr_dbd will prevent > me from proceeding once I get the constraint violation. OK, fairy nuff. Bojan's proposed patch (or some variant on it) will set transaction mode. How about if we add a further APR_DBD_TRANSACTION_CLEARERR flag (to be ORed with the mode) that'll let the application clear an error. Drivers could reset the application state and make any corresponding calls to the backend. Would you be happy with that? -- Nick Kew
