Am Monday 28 September 2009 18:26:49 schrieb Jean-Louis Leroy:
Of course I could say that all backends have three functions : start_transaction, commit and rollback. In the case of ODBC start_transaction would be a no-op. Or maybe it would turn auto-commit off (and throw if the underlying db is not tx-capable). But I am hesitating a bit. The current philosophy of my lib is much like C's : you look at any piece of code and you know exactly how it will translate into machine code. No hidden 17 dtor calls hidden inside a closing brace. From that point you either use rdb to write apps or as a foundation to build higher-level tools.
OTOH maybe I'm splitting hairs wrt transactions. Besides the two patterns above, does anybody see a third possibility ? Nested transactions ? They fit nicely in the second pattern...
I'm not sure if the BEGIN/COMMIT syntax is supported by some vendors for nested transactions, but others defniitely only support SAVEPOINT/RELEASE. so you'd have to break with your concern that you'd like the rdb SQL syntax look like what is executed under the hood anyway, if I understood it correctly. another thing, probably minor at this stage, you might want to consider is 2-phase-transactions, which would add an additional PREPARE statement, and a way to retrieve the transactions that are in prepare-state after a crash, to the interface. see e.g. http://dev.mysql.com/doc/refman/5.0/en/xa-statements.html