Re: [boost] SQL: next iteration of sqlpp11

On 2014-02-03 22:25, Johan Baltié wrote:

On Mon, Feb 3, 2014 at 7:02 PM, Roland Bock wrote:

...

On 2014-02-03 18:36, Johan Baltié 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

On Mon, Feb 3, 2014 at 6:27 PM, Roland Bock wrote: 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