Lyfar Dmitriy wrote:

Phil Endecott wrote:

...

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.

http://dtemplatelib.sourceforge.net/ Thanks, I hadn't seen that.

What do you think about containers overhead?

In my experience, which is based on PostgreSQL, you can implement STL-compatible containers for results with essentially no overhead. The most ugly part, as I have mentioned before, is mapping from a row to a tuple or struct. As far as I can see, in dtl you can use a struct (good!) but you have to define how each field should be filled from the row, and they have some magic with operator== to do so. Interesting, but it looks a bit kludgy.

Does the (a) variant means that the parsing of the result of query is something like parsing an Variant type? Is it always opportune?

With my PostgreSQL interface, I ask for the backend to pass the results in binary format, and it tells me the type for each column. I then do any necessary conversion (it may need its endianness changing; date/time formats need some effort; strings are trivial) and check that the type is what the C++ code said it expected. This is low-overhead and safe.

The people who wants to have type-safety of queries and platform independence will select the (b) variant, I hope :)

I don't understand why you say that. I want (and have) type safety. I would have portability if it were possible, but it isn't. Regards, Phil.