Add a database name fallback for early adopters of the new driver

[JanJakes]

The experimental new SQLite driver requires a database name to be set, while the old one doesn't.

There are some scenarios in which the DB_NAME constant is missing in wp-config.php. To enable easier early adoption and testing before version 3.0, we're adding a default database name in case the DB_NAME constant is not set.

Since the provided database name is now verified against the existing database, this should be a safe change.

[wojtekn]

It fixes the issue, and code change looks clean.

[JanJakes]

FYI @adamziel. Studio doesn't yet inject the missing constants into wp-config.php, so we'll add back a fallback temporarily. Since now the provided database name is verified against the existing DB, this should be a safe change.

[basil]

As a result of poor documentation, I accidentally created my database without DB_NAME, and now my SQL dump contains lots of ugly instances of database_name_here. Is there any way this can be easily repaired without starting from scratch?

[JanJakes]

Hi @basil! Could you, please, share more information about your setup and the contents of the dump? Did you use the new SQLite driver (the WP_SQLITE_AST_DRIVER constant) or the current one? Also, where does the database_name_here appear exactly in your dump? SQL dumps usually don't contain the database name itself, apart from the CREATE DATABASE statement, I think.

[basil]

@JanJakes I created the blog with the current SQLite driver and then switched to the new one by setting WP_SQLITE_AST_DRIVER. Nothing in the documentation said that I needed to set DB_NAME, so I didn't. database_name_here appears over 300 times in the dump, mostly in these tables:

• _wp_sqlite_mysql_information_schema_statistics
• _wp_sqlite_mysql_information_schema_columns
• _wp_sqlite_mysql_information_schema_tables
• _wp_sqlite_mysql_information_schema_table_constraints

When I try to set DB_NAME now to any new value other than database_name_here, WordPress stops loading.

[JanJakes]

@basil Thanks for the details. How did you dump your database? Is it an SQLite dump using some SQLite tooling? Or are you interested in a MySQL-like dump of the database?

These _wp_sqlite_ tables are internal tables that the driver needs to store extra data for MySQL-like behavior. They should not appear in a MySQL-like dump (something like wp db export, not fully supported yet), but in a pure SQLite dump/backup/export, they are necessary.

All that said, it's OK to replace all occurrences of database_name_here with any other value in your dump. Then you can set DB_NAME to that same new value, and a site from such a dump should work.

[basil]

@JanJakes I dumped my database with SQLite's .dump command. Is there any way I can repair my existing database without having to dump and reimport from scratch?

[JanJakes]

@basil You could update all the records in the SQLite database. You can use an SQLite database admin tool and run something like this:

UPDATE _wp_sqlite_information_schema_schemata SET schema_name = 'new_name';
UPDATE _wp_sqlite_information_schema_tables SET table_schema = 'new_name';
UPDATE _wp_sqlite_information_schema_columns SET table_schema = 'new_name';
UPDATE _wp_sqlite_information_schema_statistics SET table_schema = 'new_name', index_schema = 'new_name';
UPDATE _wp_sqlite_information_schema_table_constraints SET table_schema = 'new_name', constraint_schema = 'new_name';
UPDATE _wp_sqlite_information_schema_table_referential_constraints SET constraint_schema = 'new_name', unique_constraint_schema = 'new_name';
UPDATE _wp_sqlite_information_schema_table_key_column_usage SET constraint_schema = 'new_name', table_schema = 'new_name', referenced_table_schema = 'new_name';