Postgres connection handling gave the caller a way to specify what sort
of domain it needed, whereas the base class was implicitly relying on
the sequence of installer steps to ensure that the current connection
was correctly configured. The PG way of doing this is better for planned
work in this area. Exposing PG-style connection management in the base
class reduces the number of differences between PG and everything else.
Instead of PG's method of having up to three connections open, I am just
holding a single connection open, with state transitions properly
implemented.
Also:
* Deprecate direct access to $this->db.
* Factor out definitelyGetConnection(), a throwing variant of
getConnection().
* Deprecate caling getConnection() with no parameter.
* Remove setupSchemaVars(), since this was a sequence-dependent pattern.
Instead configure schema vars on transition to the create-schema
connection type.
* Use SelectQueryBuilder in databaseExists().
* Remove the pg-commit install step. This commit dates back to
bca55fa58f (March 2007), where in the old installer a commit was
done after all installation. It was moved here in 2010, but now we
have a commit in createTables() serving the same purpose. If we need a
transaction around interwiki insertion, we could do that in the base
class, but that's not what the original code was trying to do.
Change-Id: I073fb57c1b578361ac2a46ecd0cd1312c31747d4
DatabaseInstaller had some LSP violations, such as calling undeclared
methods of the supplied Installer object, assuming that it was a
WebInstaller. It was also large.
So, split the web form parts of DatabaseInstaller into separate classes.
We have a class hierarchy for the connect forms, and a class hierarchy
for the settings forms, with a base class DatabaseForm mostly as a place
to put protected helper methods.
Also, have DatabaseInstaller::getConnection() return a special subclass
of Status, so that we can remove many Phan type overrides.
Change-Id: Ie84025f8f70b895fa6882848b9a21ba1750d60e2
