Boost logo

Boost :

Subject: Re: [boost] SQL: next iteration of sqlpp11
From: Johan Baltié (johan.baltie_at_[hidden])
Date: 2014-02-04 03:34:41

On Tue, Feb 4, 2014 at 7:54 AM, Roland Bock <rbock_at_[hidden]> wrote:
> On 2014-02-03 22:25, Johan Baltié wrote:
> > Yes. It seems the safer way to me.
> OK, that would be easy to do. At least with something equivalent to
> boost::optional in the sense that when you try to access a value that is
> NULL, an assert will fail.
> I drafted a document for what I have in mind:

Great. I'll have a look.

> I have pushed the cmake change from earlier in this thread to a new
> release. It will still not compile with Windows, but at least there are
> better chances now that it does start to compile. I'd be interested in
> the error messages!
> Maybe it is just a few fixes? I know that there is trouble with '= default'.

I'll try to compile it.

> No. Not yet.
> I guess it will be hard to say: "sqlpp11" is this much faster or slower
> than XYZ. It really depends on the connector library, I'd say. sqlpp11
> is the frontend that compiles your SQL expression into a string (or
> something else). The connectors available today give that string to the
> C library and return the results.

By definition you should be slower than the library you're built upon,
at least when it is used the same way you do.
What's someone need to know is:

* What's the overhead ?
* Will it encourage neat usage of the underlying library or will there
always be a much faster way using the raw driver ?

> But it would certainly be a good idea to compare with SOCI or CppDb for
> example using the existing connectors. I'll look into that as soon as I
> find time.
> Do you know of existing comparison setups?

I've done some on my own to bench OCI (Oracle Connection Interface)
versus ODBC Oracle buts that's all.
When speaking of performance in a client database layer, I think the
main concern is bulk insert/retrieve and also database specific type
usage (date, extended numbers blob, etc...).



Boost list run by bdawes at, gregod at, cpdaniel at, john at