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

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-03-17 20:19:25

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.