Re: [boost] [std_rdb] [rdb] 0.0.09

Subject: Re: [boost] [std_rdb] [rdb] 0.0.09
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-10-01 14:16:15

Hi Vicente,

I think these are all good ideas, but I don't think a generic relational 
database layer is the right place to put them.
take e.g. if you wanted to extend BoostSTM to support making some objects 
persistent. a layer that emulates nested transactions, begins and rolls back 
transactions based on RAII etc. would be an obstacle.
abstracting the features a backend DOES support and provide a generic boost 
interface to them is hard enough given the various SQL dialects, and is a 
good basis to implement your ideas.
if you start to emulate features a db doesn't supoprt, you end up emulating 
isolation levels the db doesn't support (not trivial), emulating 
2-phase-transactions, and emulating half a RDBMS eventually.

Am Thursday 01 October 2009 08:06:48 schrieb vicente.botet:
> Hi,
>
> First, thanks for trying to provide yet another relational database C++
> front-end library.
>
> I have some general remarks. As the query language the DSLE emmulates is
> SQL, dont you think that you could put it in a specific sql directory and
> namespace. Other query language can be provided as Joel has already shown.
>
> More inline ...
>
> ----- Original Message -----
> From: "Stewart, Robert" <Robert.Stewart_at_[hidden]>
> To: "List to discuss standard rdb"
> <std_rdb_at_[hidden]>; <boost_at_[hidden]>
> Sent: Wednesday, September 30, 2009 5:37 PM
> Subject: Re: [boost] [std_rdb] [rdb] 0.0.09
>
> > Jean-Louis Leroy wrote:
> >> 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
> >
> > If you provide an RAII class that does a start/begin/whatever in the
> > ctor, a roll back in the dtor unless cancelled or committed, and provides
> > member functions to commit or cancel on demand, then all back end schemes
> > should be covered.
>
> I agree that a transaction abstraction is nedeed to encapsulates the
> patterns
>
> transaction() {
>   db.set_autocommit(off);
> }
> ~transaction() {
>   if not commited db.rollback();
>
>   db.set_autocommit(on);
> }
>
> or
>
> transaction() {
>   db.begin_transaction(off);
> }
> ~transaction() {
>       if not commited db.rollback();
>
> }
>
> Note please the following C++ schema
>
>     for (transaction T; !T.committed() && T.restart(); T.commit()) {
>
>     }
>
> That allows us to reiterate as far as the transaction has not successfully
> commited. The transaction will off course rolled back if not commited on
> its destructor. This schema has the advantage to preserve the block
> structure, and the library could provide a macro.
>
> #define BOOST_RDB_ATOMIC(T) for (transaction T; !T.committed() &&
> T.restart(); T.commit())
>
> that allows to have language-like atomic blocks
>
>     BOOST_RDB_ATOMIC(T) {
>         // do something atomic
>     }
>
> TBoost.STM  provides already some of these language-like macros.
>
> The autocommit feature can also be emmulated for backends don't providing
> it. A autocommit off will create a hidden transaction, which will be make
> the commit and rollback functions to restart the hiden transaction. A
> autocommit on will associate a transaction to the execute function.
>
> If Boost.RDB provide both, free to the user to choose its prefered style.
>
> > The ctor can throw an exception should a particular back end not support
> > transactions.
>
> If the backend do not support a feature it will be preferable to have the
> information at compile time, isn't it?
>
> > Whether a back end supports nested transactions or not puts a wrinkle in
> > the abstraction, of course.  I suggest that you model nested transactions
> > and simulate them for back ends that don't support them.  In the latter
> > case, the transaction class must use functions in some implementation
> > layer that will track outstanding "nested" transaction objects in order
> > to correctly decide whether to actually roll back when a transaction
> > object's dtor runs or when commit() and roll_back() are called based upon
> > what has already happened to the underlying, tracked state.
>
> I agree again. This seems not too complex to simulate.
>
> Best regards,
> Vicente
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost