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