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
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
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? the 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
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
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
since this closely mirrors some of the ACID concepts you need for transactions in a database. So we would have
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
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(); 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.