Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk