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

Subject: Re: [boost] [std_rdb] [rdb] 0.0.09
From: Jean-Louis Leroy (jl_at_[hidden])
Date: 2009-10-01 12:53:33

> First, thanks for trying to provide yet another relational database C++ front-end library.
>
>   
Well sometimes I feel that I am re-inventing the wheel (except maybe the 
static typing) but I need a Boost rdb layer to base a Boost 
object-relational mapper upon so...

> 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.
>
>   
Well I thought exactly the same last night. I also know that there is 
another query language, closer to relational algebra, that some people 
would want to have.

So I put everything sql in boost::rdb::sql and its own directories. 
rdb::odbc only minds that the concepts are properly implemented, except 
for one type : select_statement_tag, which maybe doesn't really belong 
to rdb::sql. Other query languages would also make it possible to create 
queies, wouldn't they ? Maybe I should rename it to query_tag and put it 
straight in boost::rdb.

>
> 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
>     }
>   
Those macros look nice. However, I agree with Stefan. Currently I can 
define the scope of my work in one sentence, without any "except for"'s. 
OTOH I know that if I had to use my own lib right now, one of the first 
things I'd do would be to implement features like you describe. I had 
them in my previous works on ORM (nested tx implemented as a nesting 
count, when it drops to zero, commit etc).

Maybe this could go in  a decorator class in a rdb::utility namespace ? 
Hmm. In fact this looks like a Database, in addition to rdb::odbc, 
rdb::mysql etc we could have a yet another "backend" with extra 
functionality...

J-L