Re: [boost] Interest in an ODBC library?

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2005-08-23 14:45:19

Hi Corwin,

Do you think our interface should support bi-directional iteration to
avoid the pitfalls you mention with input iterators, or should we only
support input iterators to support the broadest number of
implementations?  Do you know of any databases whose native APIs don't
support bi-directional iteration?

> Binding design:
> - In DTL we wanted to go away from the MFC model of forcing you to
inject
> our code into your classes.  Instead we defined operators that specify
the
> mapping relationship between columns in your query and members in your
> class. I think this is a good model since it keeps the database
mappings
> from getting tangled up with the class logic.  This kind of design is
also
> used very successfully in the Java world by popular projects like
> Hibernate
> which let you define your class as you need and simply ask you to
provide
> XML type mappings.  I'm also not a big fan of frameworks that force
you
> into
> a particular class design.
> Here is a link from DTL showing this:
> http://dtemplatelib.sourceforge.net/dtl_introduction.htm
> 
> Here is an example of a hibernate mapping:
>
http://www.hibernate.org/hib_docs/v3/reference/en/html/quickstart.html#q
ui
> ckstart-mapping

I agree with your non-intrusive philosophy.  It's been suggested that
any binding/serialization is going to have something in common with
Boost.Serialization, and I agree.  Personally, I'd like to see if it
would be possible to just get a simple database library in boost first
and do the serialization/binding (which could live in
Boost.Serialization just as easily as Boost.Database) later.

> Transactions:
> In ODBC, at least, there is not a database independent notion of a
> transaction.  Instead, when you commit, you commit everything open
against
> that connection.  So if you want multiple transactions you need
multiple
> connections.   We went with C++ try...catch logic to handle
transactions
> since this closely mirrors some of the ACID concepts you need for
> transactions in a database.  So we would have

You might check out the "scoped" transaction management class in the
sandbox (boost-sandbox/database/transaction.hpp) that Caleb suggested.

   transaction t(database);

      //do something with database

   
      //if commit is not called
      //rollback is triggered
      //in ~transaction
   t.commit();

> More later... anyway I would be interested in helping on this project
but
> don't know how much time I will have to commit to it.  I definitely
like
> the
> idea of defining the base layer in terms of simple operations so that
it
> can
> support both ODBC and native drivers since I think this would be a big
> advantage for situations where and ODBC driver simply is not available

A modern c++ database interface implemented across several databases and
operating systems will be really useful.  It's pretty simple too - this
is low-hanging fruit.

If you get a chance you might check out the project in
boost-sandbox/database.  I'm working on the documentation now (and
learning quickbook) but I posted a simple test program illustrating its
use a few days ago.