Re: [boost] SQL: next iteration of sqlpp11

On 2014-02-06 09:26, Johan Baltié 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

On Wed, Feb 5, 2014 at 11:24 PM, Roland Bock wrote: 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