Bojan Smojver wrote: > Here is the patch along the lines of setting the modes of the > transaction. It doesn't have "force commit", but if the list decides > that it's the right thing to do, I'll rework. I didn't test this - > it's just a prototype. A patch for folks using MySQL is included as > well.
Looks pretty good to me. I think you're right that we only need commit and rollback as options for the end of a transaction, but for possibly surprising reason (see below).... 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. 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. Applications using apr_dbd without transactions already have to handle all the possible errors that they care about from the databases they're using. We don't, for example, have the apr_dbd drivers attempt to map all possible DB errors to a standard set of APR errors -- that would just be an impossible task, I think. So I'm inclined to say that when using transactions, things should be no different; apr_dbd should get out of the way and let the application decide which errors it can recover from. Here's another real-life example; this one is database-specific. I sometimes register application-defined error codes with Oracle and then set up triggers to throw those errors based on some PL/SQL logic. These are errors that are meaningful to my higher-level application and in some cases signal it to do something else; I don't really want apr_dbd deciding that one of these errors means the whole transaction is bad. Thoughts, flames? Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
