Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk