[boost] [rdb] rdb/persistent integration (was: Re: [std_rdb] [rdb] 0.0.09)

Subject: [boost] [rdb] rdb/persistent integration (was: Re: [std_rdb] [rdb] 0.0.09)
From: Stefan Strasser (strasser_at_[hidden])
Date: 2009-10-03 12:27:22

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