-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Brian Braatz
My goals: 1- functional drop in replacement for ADO recordset 2- Dynamic and static "views" and indexes 3- binding model that does NOT force you to use the bindings supplied with the library this is something ADO lacks, and something I have had to work around to great frustration 4- the ability to COPY from one table<> to another table<> * ADO does NOT ALLOW you to copy recordsets. (brilliant no?)
Hi, I've spent a lot of time developing a database library and a binding language on top of it the past year and finally catching up on this thread I just have to throw a few cents in. 1) Rather than basing it on ODBC, it might be nice to have a boost::database library for which there could be multiple implementations such as ODBC, (native) postgresql, etc...: boost::database d = boost::odbc::open(...); d = boost::postgresql::open(...); d = boost::msql::open(); ODBC is not always available or desirable. 2) With this done it's not too hard to write a non-intrusive DSEL for binding on top of it. I wrote one that supports dependent tables, automatic mapping to STL containers, boost::optional, and common data types like boost::posix_time::ptime. A simple example of the language might look like: table("customer") [ *field("id") = &customer::id, field("name") = &customer::name, field("number") = &customer::number, table("tax_exempt")[ -field("customer"), field("state_id") = &tax_exempt_data::state_id ] = &customer::tax_exempt ]; The structure customer has members id, name, and number. The id field is its key. It also contains an optional tax_exempt structure that resides in a table called tax_exempt and whose "customer" field is related to the customer's id field. Especially when dealing with nested data structures, the queries generated by the library are far more optimized than what one could easily write by hand, both for saving and loading. 3) On a bit of a tangent, it's also handy to have a DSEL for generating SQL criteria strings. It's so easy to make typos or forget 's on strings: field name("name"); field number("number"); //s = "name = 'bob' OR number < 5"; const string s = criteria(name == "bob" || number < 5); If any of that sounds useful I'd love to help out. Brock