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.
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
> 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.