Subject: Re: [boost] SQL: next iteration of sqlpp11
From: Roland Bock (rbock_at_[hidden])
Date: 2014-02-06 05:52:07
On 2014-02-06 09:26, Johan Baltié wrote:
> On Wed, Feb 5, 2014 at 11:24 PM, Roland Bock <rbock_at_[hidden]> wrote:
>> Not sure if I fully understand your meaning, but here are some
>> additional comments:
> I was just saying that I prefer to have a library where the database
> connector is implemented and where you can do classic stuff using raw
> strings and having no compile time check and another one built on top
> that allows you to have that compile time check/expression tree
Thanks for the explanation :-)
>> Lowest common denominator:
>> sqlpp11 builds an expression tree. Whoever interprets the expression
>> tree can decide how to interpret it and what to accept. So for instance,
>> sqlpp11 supports outer join (of course), sqlite3 does not. If you give
>> an expression containing an outer join to the sqlite3 connector, a
>> static assert will inform you that this won't work. In a multi-database
>> connector, you might need to replace the static assert by a runtime
> That's great I think.
>> Can you give me a few examples of the specific things you have in mind?
>> I probably won't add them to sqlpp11 directly, but I would like to
>> provide the means to add them without pain.
> The thing I was thinking of when writing the previous mail was:
That's looks like a really a nice feature!
I have to give it some more thought, but I believe that it would be
possible to write an appropriate extension even today via composition
[forward standard calls to select_t]
[add your vendor specific stuff]
Another option would be to use policies to add features. That is not
possible today, but shouldn't be too hard to do either.
Thanks for the link! That's given me a lot to think about and may very
well result in a more flexible design with leaner classes. Too bad I
have to do my day job first ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk