Hajo Kirchhoff wrote:
I'd like to gauge interest in an odbc wrapper library.
This subject is recurring, with some peaks divided by long periods of complete silence. :)
I am currently writing one and the most important difference to other libraries I've seen is the ease with which my library allows binding variables to odbc columns and parameters.
Given a table in the database named 'my_table' and a struct my_table, this would be the shortest code to retrieve all rows of that table and do something with them:
odbc::table t; my_table data; t.bind(data); //!!! This does all the binding! t.open(); while (t.fetch().ok()) { }
What I don't like in your approach is that you require that there is a type (my_table above) for each different rowset traversal "profile" - this is a table in your case, but why not query just a subset of rows? I have seen an application with a table containing 150 columns (no joke, and add to this joins with other tables) and of course, all queries were interested in only some of the columns - from 2 to 5, typically. Do you require that the application always retrieves all columns? Just imagine a single table with 4 columns - there are 15 different subsets of columns there (not counting the queries with no columns). Now, imagine a table with 10 columns. What about 150? What about joins? You does your approach scale in this aspect? In my humble opinion, a DB library needs to be usable also with the assumption that each query in a program can potentially retrieve a *different* set of attributes (columns).
Note that this is the full, actual working code, not pseudo code.
Take a look at this: http://soci.sourceforge.net/ In the context of Boost, you might be interested in this informal page: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Relational_Da... -- Maciej Sobczak http://www.msobczak.com