Boost logo

Boost :

Subject: [boost] [rdb] 0.2.00 - bind parameter and result + dynamic sql
From: Jean-Louis Leroy (jl_at_[hidden])
Date: 2009-11-05 15:09:39

I have uploaded version 0.2.01 to the vault. It contains two new major

The first is the ability to bind parameters to variables allocated
outside the prepared statement, e.g.:

  // in the following examples the database contains:
  // id first_name name age
  // 1 Homer Simpson 37
  // 2 Marge Simpson 34

springfield_fixture) {
    person p;
    BOOST_AUTO(st, db.prepare(select(p.first_name).from(p).where( ==
    integer id_param;
    id_param = 1;
    BOOST_RDB_CHECK_SELECT_RESULTS(st.execute(), "((Homer))");
    id_param = 2;
    BOOST_RDB_CHECK_SELECT_RESULTS(st.execute(), "((Marge))");

The possibility of passing parameters to execute() remains but this is
more efficient, as execute(params) binds the parameters each time it is

Likewise, it is now possible to bind results, e.g.:

springfield_fixture) {
    person p;
    BOOST_AUTO(st, db.prepare(select(, p.first_name).from(p)));
    integer id;
    varchar<30> first_name;
    st.bind_results(id, first_name);
    BOOST_AUTO(results, st.execute());

    BOOST_CHECK_EQUAL(id.value(), 1);
    BOOST_CHECK_EQUAL(string(first_name), "Homer");

    BOOST_CHECK_EQUAL(id.value(), 2);
    BOOST_CHECK_EQUAL(string(first_name), "Marge");

The second feature is dynamic creation of statements. A fully static
system doesn't make it possible e.g. to create a search form, where you
enter (optional) values and the program returns a list of matching values.

Dynamic statement parts (lists of expressions, columns, tables) are
created via the make_dynamic() function. It returns a "stable" type,
which does not incorporate the full type information for the
encapsulated sql code. This makes it possible to create dynamic
collections of sql constructs and pass them to a statement. Static and
dynamic parts can be miexed freely.

For example:

springfield_fixture) {

    person p;

    dynamic_boolean predicate = make_dynamic( == _);
    integer id_param;
    dynamic_values params;
    id_param = 1;
    BOOST_RDB_CHECK_SELECT_RESULTS(st.execute(), "((Homer))");
    id_param = 2;
    BOOST_RDB_CHECK_SELECT_RESULTS(st.execute(), "((Marge))");

Here a dynamic boolean expression is used in the where clause. It
contains a parameter so it is necessary to pass a collection of dynamic
values when executing the statement.

Here is a more complex example:

springfield_fixture) {

    person p("husband");
    person spouse("wife");
    partner::qualified link;
    dynamic_expressions exprs;
    dynamic_tables tables;
    dynamic_boolean predicate = make_dynamic( == link.husband &&
link.wife ==;
    BOOST_AUTO(st, db.prepare(select(p.first_name, exprs).from(p,
    varchar<30> him;

    dynamic_values results;
    varchar<30> her;

    st.bind_results(him, results);
    BOOST_AUTO(cursor, st.execute());

    BOOST_CHECK_EQUAL(string(him), "Homer");
    BOOST_CHECK_EQUAL(string(her), "Marge");

Here the projection is partly dynamic, and so is the table list and the
where clause. Static entities are checked at compile-time as usual, and
dynamic entities at run-time - and thus may fail with an exception.
However, the system is designed to (attempt to) minimize the risk of
type mismatch in the dynamic parts - no casts are required in client
code (nor in the implementation ftm).

The test suite contains several other examples of dynamic statements
(see test_odbc_dynamic.cpp).

At this point I feel that all the major features in the scope of this
project have been addressed. Okay a lot is still missing - e.g. more
types (currently only integer and varchar are supported), constraints,
count() and such functions, group/order by... - but all these should be
easy to implement in the existing framework. And the thing needs
cleaning up and documentation, plus testing on Unix.


Boost list run by bdawes at, gregod at, cpdaniel at, john at