Re: [boost] SOCI 2.2.0 - The C++ Database Access Library

From: Edward Page (eopage_at_[hidden])
Date: 2006-12-05 13:53:58

Hello,

I'm pretty much a lurker on this list that loves to watch what is new
coming out and learn from the discussions.  A database library
interests me a lot though, so for once, I have questions.

1. Transactions

begin, commit, and rollback are provided.  I did not see any comments
in the docs of code to help keep this exception safe.  Should the
burden of exception safety be passed onto the library?
One possibility is Begin returns a "Transaction," a proxy for a
"Session," that has a commit function, and will call rollback in the
destructor.  A transaction proxy would give the impression that
several independent proxies may exist, which I am not sure if that
could be made accurate, but if not at least it is a thought.

2. Query Construction

I read the rationale for not having a query construction syntax.  To
sum up my understanding of it: when working with DBAs it is good to
have queries separate.  For some of us hobbyists or for prototyping it
might be nice, especially so we do not have to worry about syntax
issues that are minor and wouldn't show up till runtime.  If the query
construction was built on top of taking strings then it would still
allow for users to choose whether to use the query construction or to
have the expressions stored in a file.  This converting it to a string
could even be used to easily stream out all of the expressions to a
file to ease transition from a compiled version to a runtime file
version for the DBAs

One possibility is:
sql << select("name", "salary").from(persons).where.("id = ",id),
      into(name), into(salary);

Original (From webpage):
sql << "select name, salary from persons where id = " << id,
      into(name), into(salary);

The where clause could be templated to allow id to be whatever type
(using stringstream or lexical_cast?) to provide simiilar behavior to
the "<< id"

Some improvements could include:
*Setting up column objects:  It would take a column name and what
table it is from.
1) Could serve as a precondtion: That the column does exist in the table
2) Generate the from clause for you
For example:
Column personsName ("name", "persons");
Column personsSalary ("salary", "persons");

sql << select(personsName, personsSalary).where.("id = ",id),
      into(name), into(salary);

*lambda like expressions for generating the where clause.  It could
then be simplified
...
Column personsId ("id", "persons");
sql << select(personsName, personsSalary).where.(personsId == id),
      into(name), into(salary);

With this, it could even be improved by tempaltizing the Columns for
what type should be contained therein.  Then the where clause
expression generator could compare the template type of "personId" to
"id"

A potential complaint is that this makes it too easy to mix tables
unintentionally.

This is not meant as critisism or something to hold up a review, but
suggestions for refining the API according to my limited understanding
of code design and SOCI.  Reasons for these to not work or
improvements on these ideas are definetly welcome.
Ed Page