Re: [boost] Interest in Database Template Library?

From: Corwin Joy (cjoy_at_[hidden])
Date: 2001-06-02 10:43:59

----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
To: <boost_at_[hidden]>; <boost_at_[hidden]>
Sent: Saturday, June 02, 2001 8:23 AM
Subject: Re: [boost] Interest in Database Template Library?

> At 10:06 PM 6/1/2001, Corwin Joy wrote:
>
>  >...  So, I guess the question is, would
>  >there be significant interest in our trying to "boost" this library...
>
> There is certainly going to be a lot of interest.
>
> Questions:
>
> * Can it serve as an interface to multiple database backends?

Yes, in the sense that it goes through the ODBC interface.  So, we've tested
the library versus Access, SQLServer, Oracle, and MySQL to avoid doing
anything database specific.  Our users also have had success in running this
against Sybase and several other database back ends.

No, in the sense that we have not yet abstracted out the bottom layer of the
library to allow it to easily hook to layers other than ODBC.  So, a few of
our users have requested that we try to abstract out the bottom level as an
API so that this can be hooked on to native APIs for Oracle, SQLServer etc.
We're hoping to do this at some point, but have not yet done it as we are
looking for a bit of help since we are not native API experts and don't want
to get the abstraction wrong.
>
> * Is there a portable, freely available database backend?
>
Yes.  In addition to running versus Microsoft ODBC, we also run against
unixODBC under Linux ("The unixODBC Project goals are to develop and promote
unixODBC to be the definitive standard for ODBC on non MS Windows
platforms." - see details at http://www.unixodbc.org/).  However, as far as
I know, unixODBC currently only runs on Linux and FreeBSD.  For other unix
platforms (Solarix, HP-UX, AIX, SGI) one would likely have to buy an ODBC
driver from Merant :-(.

> * What are the restrictions on the value types which can be put in
> containers?  Certain specified types only?  POD's?  Pointers?

The types that we support are PODs + std::string and a 'date' class.

>
> * What is the abstraction cost?  For example, since the STL container
> interface doesn't distinguish read access from write access, are you
forced
> to re-write every element touched by an iterator, resulting in a huge
> penalty compared to a native database implementation?

For the low level input / output iterators the cost is not high.  These bind
directly to a single SQL statement such as 'SELECT' or 'INSERT' and since
they are not 'simultaneously' read and write they need only send the
elements specifically requested via an assignment to an iterator.  The full
blown containers, however, do try to be more sophisticated and hence incurr
more overhead. We should have some more detailed timing statistics out next
week.

>
> * How are issues of multi-user update locking handled?
>
The multi-user locking is assumed to be handled through the database.  As
for concurrency, this only plays a role in terms of the higher level DBView
containers for an entire table.  Here we assume Optimistic Concurrency and
when the user attempts a write then we can check the old row values to
determine if an update conflict has occurred and throw an exception at that
time.

 > * How are commit/rollback issues handled where multiple database
> interactions have to be viewed as a whole to complete a transaction?
>
Thanks to some discussions with Dave Abrahams we think we have a good C++
exception based answer to this.  It's a bit involved for a short e-mail,
however, so see the following link's discussion on "range commit and
rollback". http://www.geocities.com/corwinjoy/dtl/ExceptionHandling.htm

> * In general, what are the limitations?
>
> I guess what I'm trying to understand is the extent to which your library
> is robust enough to be used in production applications with all the
> attending messiness.
>
In general I think what we have is fairly full featured and quite robust but
there are still some odds and ends that we have on our wish list:
1. Improved support for BLOB data types.
2. Additional 'convenience' read/write iterators to loop through record
sets.
3. Other? (It's been out for about 6 months now with approximately 1800
downloads so we're still soliciting feedback on additional features.)

Thanks,

Corwin