Le 11/11/13 23:16, Roland Bock a écrit :
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... (here check the C++11 one at the bottom) I see use cases for printf and regex for instance, where the user
On 2013-11-11 22:41, Abel Sinkovics wrote: 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