On Feb 15, 2005, at 4:22 AM, Federico Di Gregorio wrote:
If the database support transactions and an exception is raised the DatabasePool does a .rollback() (if I remember correctly). In this case you're sure the query has not been executed (it was rolled back explicitly.)
If the database server returned an exception and you can actually execute a rollback, the connection didn't die. :) That is not the situation we're talking about. It's when you send a command over the network, and the remote host maybe gets it, or maybe not, and then you unplug your net connection before you get a response. You don't know if the server got the command or not. However, your point stands: If you're in a transaction and failed anything but the commit, then you know the transaction was unexecuted. If you fail the commit command, it's harder. With certain errors you know came from the database server rather than the network, you can probably also know it's unexecuted, but in some cases it's unclear. In contrast to my previous message, I do believe cp_reconnect will notice a failed connection before attempting a query on it, since it checks the result of db.cursor() when starting the transaction, and if that fails, reconnects. This is likely sufficient for most website-like application, where a failed query just results in the user pressing reload anyways. For a more serious application, it should handle any errors sensibly, including those that happen at commit time, so it needs to be able to handle errors itself, in any case. James