Re: [boost] SQL library with full embedded SQL-syntax

From: Lyfar Dmitriy (dlyfar_at_[hidden])
Date: 2007-03-17 15:19:49

Hello, sorry for my long responce.
Rene Rivera wrote:
> Sure... But we could use that same argument to propose that we write C++
> programs by writing an abstraction on top of C++ compilers in Python so
> that we can remove the incompatibilities in the various C++
> implementations. Having had the displeasure of dealing with PL/SQL there
> is one serious drawback to the language embedded approach, it ties ones
> to the capabilities of the abstraction.
May be you right, but I think that that comparison is incorrect, because of
as far as I know SQL-standart doesn't include many useful features from
various databases, opposite, the C++ standart, which is describes the whole
language :)
The main goal of the abstract layer for that library is, as Thorsten said,
is to provide "portable" SQL for at least a simple queries. There is no goal
to emulate features of each db for others at the first time.

> Jorge Lodos wrote:
> Sorry, I don't see how any of this applies -- just because the SQL is a
string
> doesn't mean it comes from an untrusted source.  And, programmers that
don't
> validate input from untrusted sources deserve what they get....

 I'd like to draw an intermediate conclusions:

1) The SQL library should provide a backdoor so you can still use
string queries if you need to be non-portable or cutting egde etc.
2) Embedded SQL commands is type-safe, but strings are flexible and more
useful in the 'real world'
3) It's hard to write one big abstract layer for all databases with single
functionality and many people doesn't need in it usually.
4) ...?

Phil Endecott wrote:
> Well, an interface is not much use without some sort of implementation
> behind it.  Possible implementations for a "generic relational
> interface" include an SQL database, on-disk data structures implemented
> using something like stxxl, and in-memory data structures made
> persistent using serialisation.  A measure of a good generic relational
> interface could be that it works well with all of these implementations.
>
> Thinking just about SQL backends, the basic question is whether we want to
>
> (a) hide the SQL, making the database accesses look more like C++
> function calls and data structures, or
>
> (b) make the SQL explicit, making the C++ code look more like SQL.
>
> I definitely vote for (a), and the possibility of moving an application
> to something like stxxl is one of my motivations for that.

If you interested in such libraries -- take a look at database template
library(dtl)  also. What do you think about containers overhead?
Does the (a) variant means that the parsing of the result of query is
something like parsing an Variant type? Is it always opportune?
The people who wants to have type-safety of queries and platform
independence will select the (b) variant, I hope :)

 -----
Best Regards, Dmitriy Lyfar