So when an extension adds a new database type, it's impossible to add the new dbtype to this array, causing Notice: Undefined index: *** in .../includes/db/Database.php on line 876
Version: 1.24rc
Severity: normal
So when an extension adds a new database type, it's impossible to add the new dbtype to this array, causing Notice: Undefined index: *** in .../includes/db/Database.php on line 876
Version: 1.24rc
Severity: normal
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
database: Gracefully fail when non-standard dbType has no default schema | mediawiki/core | master | +19 -0 |
skizzerz wrote:
There's definitely a change that needs to be made here (at the very least it needs to gracefully fall back to no schema if the $dbType isn't in the list without emitting an E_NOTICE for not finding the index), but I'm not certain that a config variable is necessary for this, for a couple of reasons.
An alternative would be a new hook to define the default schema for a new database type, it would be passed in $dbType and &$schema (which allows for setting a single schema for that database, defaulting to null). This way we avoid the pitfalls of point 2 by not allowing the defaults for existing drivers to be changed, while also avoiding the extra boilerplate required in the solution presented in point 1 in the event a db object needs to be constructed multiple times.
Change 134562 had a related patch set uploaded by Skizzerz:
(bug 64365) Gracefully fail when getting the default schema if we get a non-standard db type instead of throwing notices. Also add a hook to allow extensions that add non-standard types to configure said default
Change 134562 had a related patch set uploaded by Krinkle:
database: Gracefully fail when non-standard dbType has no default schema
Change 134562 had a related patch set uploaded (by Liangent):
database: Gracefully fail when non-standard dbType has no default schema
Change 134562 abandoned by Krinkle:
database: Gracefully fail when non-standard dbType has no default schema
This code now lives in MWLBFactory, where based on the private getDbTypesWithSchemas(), the DBmwschema config is passed to the specified IDatabase implementation.
The registry for IDatabase classes is open via DBtype, but the list of getDbTypesWithSchemas() is private.
Rather than exposing that internal array via a hook, I'd rather get rid of it entirely. Perhaps we can just pass it to Database::factory unconditionally and let some backends ignore it?
IMO we should probably rethink the whole concept of "schemas" in MediaWiki. Starting with defining terms:
MySQL has only one database per server. What it names "database" is actually a schema by these definitions, which is the root of all the confusion on this topic.
PostgreSQL has multiple databases per server. Unfortunately when someone originally implemented PG support they didn't realize that what MediaWiki was calling a "database" is actually what PG calls a schema, leading to the confusion on this topic.
SQLite doesn't have a server. Each file is basically one schema, and each schema you want to use needs to be explicitly opened (see https://www.sqlite.org/lang_naming.html).
I don't know about MSSQL and Oracle, and I don't want to spend the time researching them to work it out.
MediaWiki generally expects to work out of one schema at a time. The Database class basically represents a connection to a schema; we generally try not to do cross-schema queries to keep flexibility for scaling by moving schemas to different sections. LoadBalancer/LBFactory try to manage connections to databases by changing a spare Database object's default schema instead of reconnecting.
TL;DR: Everything MediaWiki calls a "schema" is bogus. We need to rework the PG abstraction layer to map MediaWiki's idea of a "database" to a PG schema, then we should be able to drop MediaWiki's idea of "schemas" entirely.