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

Subject: Re: [boost] [std_rdb] [rdb] 0.0.09
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-10-01 15:45:26

Hi Stefan,
----- Original Message ----- 
From: "Stefan Strasser" <strasser_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, October 01, 2009 8:16 PM
Subject: Re: [boost] [std_rdb] [rdb] 0.0.09

> 
> 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.

I don't see why this could be an obstacle. Could you clarify your concern?

> 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.

I agree. I think the work done on Boost.RDB could be a great work. If we can implement my ideas on top of the RDB library this will mean that the library is enogh open, but we need to probe it. Could my proposed features be implemented without any change? Otherwise we need to see what is needed at the library inteface to allow it. Only then, the proposed interface could be considered as close. Of course this is a personal opinion.

> 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.

Well, I've not asked to emulate 2-phase-transactions or tleast not yet. If the backend do not support a given abstraction, it is good to know it, and in my opinion a compile time error will be the best in this case.

Best regards,
Vicente

> 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
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>