On 25/07/2014 5:49 PM, Gavin Lambert wrote:
You're assuming that all backends must be built as part of the quince tree.
Quite right: I assumed that, and I shouldn't have.
What if I wanted to write a backend private to a particular application and never intended to be published (perhaps it's some proprietary data format rather than a "real" database)?
If the core were always built, it could be used with a custom backend that quince's jam file knows nothing about.
Fair enough, and we have since heard from Roland and Rob, so I think we have consensus: quince should get built regardless of whether any of the third-party libraries that I had in mind are already installed, and regardless of what is decided about shipping sqlite.
(Provided that the core itself doesn't have to be modified to add a new backend -- but I would hope that's true as it's part of standard coding principles.)
I share your hope. :) When I look at quince+quince_postgresql+quince_sqlite, I can tell you that all the DBMS-specific code is in the hands of the backends. Quince has various classes with virtuals, and the backends have classes that override those virtuals to do backend-specific things. And I've tried to future-proof it, e.g. by putting "virtual" on all the functions that generate SQL phrases, whether they currently have backend-specific behaviour or not. Unfortunately, however, I don't have a formal specification of exactly which ways DBMSes are allowed vary, so I can't guarantee that that a new DBMS won't provoke some unanticipated, unimagined change to quince itself.
I'm coming around to Karsten Ahnert's idea that I should ship sqlite. (I wouldn't call it a "default backend", as Karsten does, because application code still has to make a choice -- but that's just a quibble.).
All of sqlite or just a connector to it?
I'll definitely be shipping a backend (aka connector) to sqlite. But to ship sqlite itself or not? That is the question I was soliloquizing about.
I don't have any particular opinion on this either way, but bear in mind that if you do the former, users may still wish to use a different version of it (perhaps they need a bugfix from a newer version than shipped with quince), and (especially if you don't provide a way to do that) users will expect you to keep it up to date, which increases maintenance costs slightly.
Hm. On one hand, users are free to use their own backend library, which might be a very slightly modified version of quince_sqlite, to go with their own slightly different sqlite3.[ch]. And application code always has to say which backend library it is going to use for each database (see http://quince-lib.com/getting_started/creating_the_database_object.html). The only problem I see is if quince forces my chosen sqlite3.o into the link, leading to doubly-defined symbol errors. IANL (I Am Not A Linkerologist) but I suspect there is some solution based on ordering arguments to the linker, so that symbols in the user's sqlite3.o trump any in my sqlite3.o. --- Michael