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 :)