Re: [boost] sqlpp11: SQL for C++

Subject: Re: [boost] sqlpp11: SQL for C++
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-11-11 17:53:17

Le 11/11/13 23:16, Roland Bock a écrit :
> On 2013-11-11 22:41, Abel Sinkovics wrote:
>> Hi,
>>
>> On 2013-11-11 21:31, Roland Bock wrote:
>>> Metaparse requires const char[N] arguments, right? That would be a
>>> rather atypical case for using a query interface, I'd say. Personally I
>>> have never used queries without variable parameters except in examples
>>> like the one above.
>> Yes, it takes char[N] arguments, however, you can use a
>> boost::format-like syntax (as mentioned by Christof) or a printf-like,
>> type checked one.
>>
>>>>> The string could be parsed by a template metaprogram and the right
>>>>> classes could be built out of it. It could provide all the static
>>>>> guarantees you have described above.
>>>> Guessing from code here:
>>>>
>>>> https://github.com/rbock/sqlpp11/blob/master/include/sqlpp11/select.h#L574
>>>>
>>>>
>>>>
>>>> The sql string written to oss would be something like the argument
>>>> to your QUERY function.  IOW, IIUC, there's no need for parsing a
>>>> string to build the right classes.
>>>>
>>>> OTOH, the string passed to the actual database (via the db
>>>> on select.h#L574) would have to be parsed, I assume, by dbms, which
>>>> might issue some error message or return some error code if the
>>>> sql string were not right.  I think Roland's code almost guarantee's
>>>> the sql string would be correct.
>>>>
>>>> Is that about right Roland?
>>> That is correct, Larry, nicely guessed from the code, indeed :-)
>>>
>>> The query is constructed via functions and objects to build an
>>> expression which /can/ be evaluated as a string which is then being sent
>>> to the database. This is also the current use case. But there have been
>>> several ideas presented in this thread what else could be done
>>> (evaluating XML or JSON or incoming streams). In those cases, it might
>>> be better to transform the query into another representation.
>>>
>>> Regarding the correctness of the string: That's the goal, yes.
>> If you don't want to transform the string, just validate it (and maybe
>> do some variable substitution) you can approach it in a similar way
>> the type-checked printf does it: it parses the string, does the
>> validation at compile-time and then uses the original string at runtime.
>>
>> Code of it:
>> https://github.com/sabel83/mpllibs/tree/master/mpllibs/safe_printf
>>
>> Example using it:
>> https://github.com/sabel83/mpllibs/blob/master/libs/safe_printf/example/safe_printf/main.cpp
>> (here check the C++11 one at the bottom)
> I see use cases for printf and regex for instance, where the user
> provides a textual representation of something at compile time. In those
> cases, compile time validation of strings is a wonderful tool, and I
> have highest respect for it.
>
> But in the context of sqlpp11 I don't see how or why I should use it?
> The library is constructing the query string at runtime. There is no
> string to be validated at compile time. This is a major difference to
> most other C++ SQL libraries.
>
>
Hi,

I think that what others are saying is that as your interface is a SQL 
on, maybe a textual interfaces is even closer to the SQL one ;-)
Thus this concrete example

|for (const auto& row : db.run(select(foo.name, foo.hasFun)
                               .from(foo)
                               .where(foo.id > 17 and foo.name.like("%bar%"))))

|

|could be rewritten with something like|
||

|
| |for (const auto& row : db.run<"*select* name, hasFun *from* foo 
*where ( *id > 17 *and* name *like* "%bar%" )">()) //

This need to take care of escaping '"' or a way to quote |||"%bar%"| :(

|Clearly this interface can be learn quicker by a SQL developer and can 
be checked statically using something like Metaparser or the techniques 
used by Metaparser. Whether this is a good idea depends on
* the performances at compile time and :(
* the kind of errors the user would have :(
* there is something that can be done with the first syntax that can not 
be done with the ct-string syntax or that can be easier to do.

I can understand that you don't want to go this path as it it s complex 
and could take a lot of time to stabilize it.
Anyway, if you can show some examples that you think can not be done 
parsing a ct-string, this could reinforce your current interface.

Note that I like your EDSL interface, but a SQL EDSL interface text 
based could complement quite nicely the yours.
Both approaches could be provided either by your library or by a library 
on top of yours.

HTH,
Vicente