In order to make commits that change the schema as discoverable is possible,
I'd propose the following guidelines:
* Update RELEASE-NOTES to briefly mention the change (this is not always
necessary for follow up changes within the same release, since people
upgrading don't care about intra-release changes).
* Include "[Schema]" near the beginning of the first line of the commit.
* Mention the names of the tables that the schema was changed for as a
bullet point in the commit summary.
Also, changes should always allow for a temporary rollback strategy when
people upgrade from one major MediaWiki version to the next. The schema for
version X+1 should work with the version X code.
Mostly, this just involves doing additions in version X+1 and removals in
version X+2 or higher. More specifically:
* New tables are fine
* New columns are fine *as long as* they have default values (also one
should check for code that does SELECT * and does for loops on all fields,
which should be avoided to begin with)
* New indexes are fine (note that adding a new column and a unique index on
it can cause problems even with DEFAULT NULL for some non-mysql DBMS)
* Table removal is fine if it already wasn't used in the previous MediaWiki
version and any data worth migrating is already first migrated in update.php
with a "logged update"
* Column removal is fine if it already wasn't used in the previous MediaWiki
version and any data worth migrating is already first migrated in update.php
with a "logged update"
* Index removal is fine if it already wasn't used in the previous MediaWiki
version (one could also remove index A and add index B which also handles
the queries that used A *provided* there are no FORCE INDEX A statements
used by MediaWiki)
* Column changes that just fix prior problems or just expand the range of
values are fine (e.g int => bigint, NOT NULL => NULL, varchar => blob), as
long as it works with the previous MediaWiki version
* Index changes that are fine as long as it works with the previous
MediaWiki version (e.g. making an index not used for sorting go from
(field_sha1) to (field_sha1(8)), or doing changing and index from (field_a)
to (field_a,field_b)).
The reason I say "temporary rollback" is that during such a rollback it
might be OK for certain problems to exists. For example, in the past the
data stuffed in page_restrictions was moved to a new page_restrictions
table. Of course if some one upgraded for a while, and then rolled back,
newly protected pages would magically become unprotected (until the upgrade
was re-attempted or an admin re-protected the pages). The degree to which
these problems are acceptable depends on:
a) The likelihood of a rollback being needed (larger with more complex
changes)
b) Whether a rollback would be likely to only last for a brief time for a
hotfix or would be likely to last a long time (more so with more complex
changes)
c) How annoying the problem would be
I'd say that those things should be measured on a case-by-case basis. In
some cases, version X+1 should write to both the old and new style locations
if the risk is too high.
--
View this message in context:
http://wikimedia.7.n6.nabble.com/Commits-that-make-schema-changes-tp4990111…
Sent from the Wikipedia Developers mailing list archive at
Nabble.com.