Finish adding SQLite support

[leto]

Currently we have a SQLite schema in our repo, and instructions for creating a DB from it and regenerating the SQLite schema when it changes. Now we need to actually support it in the installer and DIY web interface.

[leto]

Here are my current ideas:

1. The installer should detect if the sqlite3 binary can be executed. If so, the installer will setup a SQLite DIY instance. If not, it should install as it does now.
2. The installer will then look at the appropriate db schema and use PDO to deploy it.
3. The framework/php/settings/cashmusic.ini.php file should learn a dbname attribute, which is the name of the database. If using mysql, it will be the database name, if using SQLite, "dbname.db" will be the file where the db is stored.
4. The commerce plant uses mysql_error(). If we plan on reviving it, we need an abstraction around database errors.

[jessevondoom]

Commerce plant is old and used the older mysql_query() structures. ALL db queries should be routed through CASHDBA or we don't accept the patch. Centralized PDO is the only civilized way.

[leto]

Just wondering: is it possible for the mysql binary to not be found, but for PDO to still work? It would be nice to be able to detect people that attempt to install CM that don't have mysql support. Is it possible to have PDO, but it not supporting MySQL? Probably a rare situation, in any case, but it is nice to be defensive and warn users early instead of giving cryptic errors.

[jessevondoom]

Not 100% sure about this, but I'm pretty sure both PDO and SQLite wouldn't report as available unless their binaries were present at compile time.

We can probably test with:

 is_defined(PDO)

and

 is_defined(SQLiteDatabase)

http://www.php.net/manual/en/class.pdo.php
http://www.php.net/manual/en/function.sqlite-open.php

[leto]

Yeah, defined checks for the objects sounds reasonable.

[leto]

This could be useful:

PDO::getAvailableDrivers()