Hi J-L, you seem to be making good progress on your rdb library, so I wanted to share with you the interface of boost.persistent that is intended to integrate a boost object-relational mapper. boost.persistent implements many of vicente's ideas like RAII transactions, a macro like the one shown below, smart pointers to access database objects like they were regular objects managed by a boost shared_ptr etc. I'm working on making boost.persistent generic enough to integrate other backends than the default one (which implements transactions and storage itself, without a RDBMS backend). so here's the preliminary interface, feedback is welcome. there are many supporting classes for serialization, object caching etc, but they are all called by the resource manager, so o-r mapping to statically defined rdb tables that you prefer can also be implemented. concept ResourceManager{ public: typedef implementation-defined transaction_token; typedef implementation-defined object_transaction_state; transaction_token begin_root_transaction(); transaction_token begin_nested_transaction(transaction_token parent); void commit_transaction(transaction_token); void rollback_transaction(transaction_token); template<class T> shared_ptr<object> new_object(transaction_token,T *); template<class T> shared_ptr<instance> get_instance(transaction_token,shared_ptr<object> const &); template<class T> shared_ptr<instance const> get_read_instance(transaction_token,shared_ptr<object> const &); template<class T> shared_ptr<instance> get_write_instance(transaction_token,shared_ptr<object> const &); void remove_object(transaction_token,shared_ptr<object> const &); //resource managers that support reference counted objects: template<class T> shared_ptr<object> new_shared_object(transaction_token,T *); void make_object_shared(transaction_token,shared_ptr<object> const &); void count_object(transaction_token,shared_ptr<object> const &,int strong,int weak); bool object_expired(transaction_token,shared_ptr<object> const &); //resource managers that support distributed transactions: void prepare_transaction(transaction_token); }; the interface is not intended to be called by the user, but is called by a transaction manager. another way to plug in another backend is implementing a StorageEngine and using the default resource manager, but a storage engine only implements object I/O, so if you wanted the RDBMS to handle the transactions, you'd implement a resource manager. Am Thursday 01 October 2009 18:53:33 schrieb Jean-Louis Leroy:
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost