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:09:09

----- Original Message ----- 
From: "Jean-Louis Leroy" <jl_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, October 01, 2009 6:53 PM
Subject: Re: [boost] [std_rdb] [rdb] 0.0.09

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

This seems a beeter organization to me.

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

IMHO, even if you don't provide this features in your library you must probe that they can be implemented without any change. I think that this can be done as examples. Only then we can see your library is open, and decide if this functionalities should be let to the users of the library or must be directly included. So, I'waiting for the implementation of the suggested features without changes on the library.

Best,
Vicente