Re: [boost] SQL: next iteration of sqlpp11

Subject: Re: [boost] SQL: next iteration of sqlpp11
From: Roland Bock (rbock_at_[hidden])
Date: 2014-02-04 01:54:50

On 2014-02-03 22:25, Johan Baltié wrote:
> On Mon, Feb 3, 2014 at 7:02 PM, Roland Bock <rbock_at_[hidden]> wrote:
>
>> On 2014-02-03 18:36, Johan Baltié wrote:
>>> On Mon, Feb 3, 2014 at 6:27 PM, Roland Bock <rbock_at_[hidden]> wrote:
>>>> On 2014-02-03 18:22, Johan Baltié wrote:
>>> What bother me is that you can have quite easily inconsistent behaviors.
>>> You retrieve values and you work with them in a select, you have no
>> warning
>>> that a null value was encountered but you have no result or worse the
>> wrong
>>> ones...
>>>
>>> It should not be the default behavior.
>>>
>> The behavior could be defined via the value_type as Bjorn suggested in
>> his post. But as soon as there is an outer join for instance, there
>> could be NULL values all over the place.
>>
>> As stated in my reply to Edward, it is tough to impossible to determine
>> exactly which columns in a result set could be NULL, if the query
>> structure is not fully known at compile time. Would you want to turn
>> everything into a boost::optional then?
>>
>
> 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:
https://github.com/rbock/sqlpp11/wiki/NULL
>
> If an user doesn't like optionals he can add something to the statement so
> that he gets non optional types and an exception if a NULL occurs. I do not
> know if it is a good design idea, but throwing an exception when you've
> asserted that you do not wan't NULL does not seems stupid.
As you can see from the document mentioned above, I'd rather offer a way
to make the .nit() call implicit. I would not want to change hundreds or
even thousands of lines of code that read in strings from the database
and really, really, really don't care if it is NULL or "".

>
> BTW it seems quite promising and interesting, sorry to hear it cannot be
> build under MSVC.
Thanks for the flowers :-)

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'.
> Do you have some benchmark against "native" drivers ?
>
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.

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?

Regards,

Roland