Boost logo

Boost :

Subject: Re: [boost] sqlpp11: SQL for C++
From: Roland Bock (rbock_at_[hidden])
Date: 2013-11-11 14:16:26


On 2013-11-11 16:00, TONGARI J wrote:
> Hi,
>
> 2013/11/10 Roland Bock <rbock_at_[hidden]>
>
>> Hi,
>>
>> over the last four or five years I developed several SQL libraries for
>> C++. With C++11 I was finally able to create an SQL library that meets
>> my own expectations and requirements. It is being used in production, I
>> recently put it on github, and I would really like to hear from you guys
>> whether this is something that could be interesting for you personally
>> or for boost?
>>
>> https://github.com/rbock/sqlpp11
>> https://github.com/rbock/sqlpp11/wiki
>>
> That's almost what I was looking for :D
Nice to hear that :-)
>> --------------
>> // selecting zero or more results, iterating over the results
>> for (const auto& row : db.run(
>> select(foo.name, foo.hasFun)
>> .from(foo)
>> .where(foo.id > 17 and foo.name.like("%bar%"))))
>>
> Is it possible to separate the placeholders of columns & tables? I feel it
> redundant to say table.column if not ambiguous.
Hmm, you could make copies of the column members, of course.

constexpr TabSample tab = {};
constexpr auto alpha = tab.alpha;
...

Maybe but the columns into a namespace to be able to differentiate in
case of ambiguities.

> In case of more than one table, maybe table[column] is a good syntax for
> that.
I don't think so. A table has a given set of member columns. Using any
kind of lookup is contrary to what I want to achieve.
>
> Does it support prepared statement?
Not yet. But it is a good point.
> Maybe another set of placeholders (_1, _2, ...) can be used to generate the
> functor.
Would you want placeholders for values? Or for columns as well? The
former shouldn't be too hard. The latter is a different story, though...
>
> Also, it'll be great if it works with Fusion & Optional, etc...
I can see Fusion for table definition (and I would require some help
with that), but where would you see Optional?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk