Choosing Qt SQL
I promised to blog a bit more about some more technical aspects of current digikam development. Today: Our database backend.
With version 0.7 a few years ago, digikam decided that it was time to use a real database. This meant SQLite2 at the time. For 0.8 and 0.9 we have been using SQLite3 which is a very good choice for local use, (complete unicode support, no configuration for users, in-process, fast) but has its weaknesses for those users who want to access a database from different computers (does not work over NFS).
All the time we were strongly bound to SQLite by using the native C/C++ API directly. Coming from that situation (and not abstracting different DBs already like Amarok) it was a clear and easy choice with minimal work to base the database backend on Qt SQL.
Qt SQL is a low-level wrapper around database APIs, this means, you still write your SQL (which I like) and have to adapt to the peculiar tastes of different db system (which I dont like, but can't be helped). It gives us for free a nice and complete API and some sweets like prepared queries. Previously, we bound values manually:
execSql(QString("SELECT id FROM Images WHERE name=%1 and album=%2;").arg(escapeString(name)).arg(albumId);
now this is wrapped in an very thin API similar to i18n calls I built around QT SQL:
execSql(QString("SELECT id FROM Images WHERE name=? and album=?;"), name, albumId);
and is internally always bound directly using the native API, but that is done for us by Qt.
Now with Qt SQL this does not mean we support MySQL (for those users mentioned above who are not happy with SQLite). We need to audit out SQL, where "we" is someone who knows about the differences...(me not)...