Re: [boost] quince: queries in C++ expressions

Subject: Re: [boost] quince: queries in C++ expressions
From: Michael Shepanski (mps_at_[hidden])
Date: 2014-07-16 21:08:00

On 17/07/2014 1:29 AM, Roland Bock wrote:
> [skipped a few items that seem to require no further immediate discussion]

No worries: I do the same now ...

> What happens with the names when I do a self join with quince?

Ah.  Then there is a problem, and there is a solution, both described at 
http://quince-lib.com/queries/join/self_joins.html

>> Indeed, this is something quince cannot do.  In order to do it, I
>> think I would need to make database type a static property of each
>> query, each mapper, etc. That would be significant and sweeping
>> complication.
>>
>> I suspect that, in 99% of cases, an application only deals with
>> databases from one vendor. A user who only wants to deal with sqlite
>> would be better served by a version of quince that didn't provide
>> postgresql-specific features at all, and didn't declare virtual
>> methods to implement them.  Perhaps a pragmatic solution would be to
>> provide that sort of quince, by means of preprocessor switches. =-O
> That's a solution, but it also means that you might have to change
> quince for each additional database dialect.
>
> sqlpp11 aims to be completely vendor neutral, offering the tools to
> adjust for dialects and non-standard features in the connector. I hope
> that in the long run this will lead to more distributed efforts :-)

Yes.  Iiuc this is a benefit you get by including DB vendor in the 
static type of your objects, i.e. a statement_t for MySQL is a different 
type from a statement_t for sqlite -- yes?

For quince I decided I preferred I wanted my queries to be simply 
query<point>, query<employee> etc.  The price I pay is that use of 
vendor-inappropriate features is not caught until run-time.  I concede that.

> I am not sure what will happen with the treat-container-as-databases
> thing, but LINQ uses that with great success and sqlpp11 offers the
> mechanisms to do the same.

Would it be correct to say that you get this because sqlpp11 does not 
generate SQL, but rather it leaves that completely to the connector 
libraries, so they are free to do something completely different instead?

I have (so far) taken the approach of centralizing as much as possible 
of the SQL generation in quince itself, with the backend libraries only 
making a contribution where there are dialectal differences.

I have not thought about this until today, but I suppose it would be 
possible to change quince so that it always calls out to backends to do 
the whole job of generating SQL and executing it; and then a 
special-purpose backend could decide to do something else instead.

If I took that approach, I think I would still want some common code to 
generate "normal" SQL, rather than repeating such code in 
quince_postgresql, quince_sqlite, etc.. Quince could provide such code, 
and it would be up to each backend library to decide whether to use it.

Cheers,
--- Michael