From: Maciej Sobczak (prog_at_[hidden])
Date: 2007-03-15 03:51:09
Jeff Garland wrote:
> Well, I'll be brutally honest -- I don't think I would go that
> direction. We didn't pick a database project last year because a
> majority of the mentors agreed that the 'dsl-based' approach was more of
> a toy than reality. The main reason for this is that in 'real-world'
> applications queries are often dynamic and must be built at run-time.
The other reason is that in 'real-world' you might want to call stored
procedures instead of manually glued pieces of ad-hoc SQL queries, in
which case the support in the area of query composition is probably not
very useful anyway.
The database library is not really about creating queries - it's about
exchanging data (but see below).
> At the point the leading candidate for boostification of basic db access
> is SOCI:
> As I understand the state of affairs, the main barrier to Boost
> submission is getting the code into the usual boost structure, writing
> additional tests and such. I"ve cc'ed a couple of principles on SOCI,
> so they may want to comment on my perception. However, if I'm correct,
> a great SOC submission may in fact be to Boostify SOCI. It's not as
> 'sexy' as the embedded SQL, but I, for one would be a big supporter.
Indeed, we are now working on boostification of the SOCI library. The
reorganization of code and change of naming convention was already done
for the core part and half of the backends - these are available for
your inspection any time from CVS (linked from the project home page).
I admit that we are progressing somewhat slowly, but I'm optimistic
about the process itself. We keep the list of suggestions gatheres
during the last wave of DB discussion on the Boost developer's list and
we will work out major points. Integration with Boost in terms of
boost::optional (for example) is at the top of our tasks.
Coming back to static SQL composition, please note that something like
this can be an add-on to the SOCI library, where the query is in fact
whatever object that is IOStream-able - we have never used anything else
than a string or string literal there, but there is nothing that
prevents you from doing some tricks with operator<<. Statically creating
the temporary object that will get streamed into intended SQL query is a
non-intrusive and optional solution that will probably make everybody happy.
-- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk