Re: [boost] SQL: next iteration of sqlpp11

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
> builder.
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
>> exception.
>
> 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:
>
> http://docs.oracle.com/cd/B19306_01/server.102/b14200/queries003.htm
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

template<....>
struct oracle_select
{
 [forward standard calls to select_t]
 [add your vendor specific stuff]
sqlpp::select_t<...> _select;
};

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 ;-)

Regards,

Roland