From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2005-08-23 14:45:19
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
> our code into your classes. Instead we defined operators that specify
> mapping relationship between columns in your query and members in your
> class. I think this is a good model since it keeps the database
> from getting tangled up with the class logic. This kind of design is
> used very successfully in the Java world by popular projects like
> which let you define your class as you need and simply ask you to
> XML type mappings. I'm also not a big fan of frameworks that force
> a particular class design.
> Here is a link from DTL showing this:
> Here is an example of a hibernate 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.
> In ODBC, at least, there is not a database independent notion of a
> transaction. Instead, when you commit, you commit everything open
> that connection. So if you want multiple transactions you need
> connections. We went with C++ try...catch logic to handle
> 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.
//do something with database
//if commit is not called
//rollback is triggered
> More later... anyway I would be interested in helping on this project
> don't know how much time I will have to commit to it. I definitely
> idea of defining the base layer in terms of simple operations so that
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk