Concerning the transactions, I thought ODBC already was the common interface beginning, committing and rollingback transactions. Please see functions SQLSetConnectAttr SQLEndTran That's how they are implemented in the current drop. However, my plan is to support native bindings. In ODBC a transaction looks like this :
set autocommit off do work commit or roll back do work commit or roll back etc This pattern is directly reflected in the current implementation. See the test suite in libs/rdb/test/test_odbc.cpp. Other vendors may have a different pattern : begin transaction do work commit or roll back begin transaction do work commit or roll back 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... J-L