Re: [boost] Interest in an ODBC library?

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2005-08-18 14:45:59

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Caleb Epstein

> Perhaps two classes of iterators could be provided?  RandomAccess for
> those platforms that support them and Sequential for the ones that
> don't.  Actually, it should be a simple matter to build RandomAccess
> iterators on top of Sequential ones for those vendor APIs that don't
> natively support RA.

I don't mind having two classes, but then do we have to make database a
template?  We've got a few choices:

1) make database a template with some sort of iteration policy
2) support only sequential iteration
3) provide only random access iteration, emulate where not available
4) provide separate begin()/end() functions for each type of iteration.

I'm leaning towards 2.

> FYI, the implementation in your email will emit multiple "BEGINS"
> ("START TRANSACTION") but only emits a single "COMMIT" or "ROLLBACK",
> which I think is a bug.

Oops again.  It should only emit one.  I'll try to invest some time
tonight getting something set up in the sandbox CVS and post a fix for
this and the <:: digraph.

> I think it would be nice to support nested transactions on those
> platforms where they exist.  Someone *might* have reason to use
> sub-transactions within a larger transaction, some of which get
> committed and others which get rolled back before the ultimate parent
> transaction's commit/rollback.
> 
> For example, a complex business process might involve inserts/updates
> to multiple tables.  Perhaps one of those operations fails in a way
> that is deemed harmless (e.g. inserting a Customer record that already
> exists), and we wish to rollback this sub-operation but continue
> processing the larger transaction towards an ultimate COMMIT.  It
> seems to me that if the underlying vendor product supports this, a
> Boost.Database ought not to stand in the way of using it.  In part
> because supporting it seems quite simple to do.

OK, I'm beginning to see the light.  We need the transactional methods
to be abstract so the implementation can determine whether to allow
nesting or to emulate it.

> That would be a very nice addition, as long as the syntax would not be
> too tortured :-)  However, I suspect some users will come up with
> baroque and complex queries that may be difficult or impossible to
> represent in this DSEL.  As with some complex grammars in Spirit, they
> may just be too much for the compiler to handle without choking or
> they may introduce unwanted compile-time penalties.

One thing that makes it easier to manage than Spirit is that the final
result is just a string so it's easy to break these expressions up
without losing valuable type information.

It's really just sugar for the most part and not high on my to-do list,
but it gets more interesting when used in conjunction with the
serialization library or with more "interesting" types like ptime.

> Supporting user-generated SQL could also ease the porting of existing
> code that already has queries embedded in it.  At the very least,
> Boost.Format or something like it could be used to build query strings
> in a type-safe and properly-escaped-string way.

Agreed.  Keying in SQL by hand in C++ is annoying and error prone.
 
> As to prepared statements, whether they be created from strings or a
> DSEL, they can be a major win performance-wise for applications which
> do lots of database writes.  The overhead of parsing the SQL on each
> insert can become suprisingly high.

I'd always thought the cost of parsing SQL to be far outweighed by the
cost of executing it, but maybe I'm wrong.  If this is an important,
portable optimization we probably need to include it.

> I stopped myself from making that same point, as there is potentially
> a large overlap with Boost.Serialization as Dave A. mentioned.  I do
> think a generalized object description framework (e.g. some form of
> Reflection) could be put to great use by a Database library, the
> Serialization library, the Langbinding code I hope will come into
> being some day, and any number of other applications.  The
> possibilities are near endless.

What is the Langbinding code?

I should have stopped too.  Excited as I am by the serialization part, I
think work on it should come after (if) there is a proposal for a
Boost.Database.  The serialization would certainly be easier with some
sort of Reflection framework.  I also anticipate a lot of simplification
when Boost.Fusion is released.  In any case we're probably better off
waiting.