Maintenance script populateRevisionSha1.php was using the deprecated
Revision class. Instead, use the new RevisionRecord class if
possible, and custom code otherwise.
Bug: T217829
Change-Id: I0c22286a16d7b243306447d8948428702269a4bd
Per documentation on IDatabase, $conds must be a string or an array.
Passing false for conds is confusing, since it's unclear whether this
should match everything or nothing.
Bug: T188314
Change-Id: I8be1ac4cbdaafc41aadc2a658be8a99b754b0268
Maintenance::commitTransaction is calling waitForReplication already.
No need to wait a second time, hopefully the lags are 0 already.
Change-Id: Id457ed2cdd6bfd9663665ba0cd5c4e3dd640b738
Deprecate the second argument to Maintenance::error() in favor of a new
Maintenance::fatalError() method. This is intended to make it easier to
review flow control in maintenance scripts.
Change-Id: I75699008638f7e99b11210c7bb9e2e131fca7c9e
Several classes have a "selectFields()" static method to tell callers
which fields to select from the database. With the recent comment table
change and the upcoming actor table change, this pattern has become too
simplistic as a SELECT will need to join several tables to be able to
retrieve all the needed fields.
Thus, we deprecate the selectFields() methods in favor of getQueryInfo()
methods that return tables and join conditions in addition to the
fields.
Change-Id: Idcfd15568489d9f03a7ba4460e96610d33bc4089
With the introduction of CommentStore, selects from various table
require certain joins or column aliases for proper operation. The
upcoming actor table change, and the suggested title table change, will
add more such requirements.
Change-Id: Ic8213bff74b8350b15cd271d0ef252e63e7e79bd
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
This includes renaming fixBug20757.php to fixT22757.php for similar consistency.
Change-Id: If81a590d658fbd82c20c54ac47dfdc8856745ca3
Add transaction methods to complement getDB().
This makes it easy to grep for direct begin()/commit()
calls to IDatabase by having script use their own
wrapper. Maintenance scripts are one of the few places
that can (and need to) use begin/commit instead of the
start/end atomic methods.
Eventually, there should be almost no direct callers
and those methods can be made stricter about throwing
errors on nested calls.
Change-Id: Ibbfc7a77c0d2a55f7fc2261087f6c3a19061e0aa
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I727deec35a712de0f0c676cc87dfa661f1ee965b
Follows-up I1343872de7, Ia533aedf63 and I2df2f80b81.
Also updated usage in text in documentation and the
installer LocalSettingsGenerator.
Most of them were handled by this regex:
- find: (require|include|require_once|include_once)\s*\(\s*(.+?)\s*\)\s*;$
- replace: $1 $2;
Change-Id: I6b38aad9a5149c9c43ce18bd8edbab14b8ce43fa
Squiz.WhiteSpace.LanguageConstructSpacing:
Language constructs must be followed by a single space;
expected "require_once expression" but found
"require_once(expression)"
It is a keyword (e.g. like `new`, `return` and `print`). As
such the parentheses don't make sense.
Per our code conventions, we use a space after keywords like
these. We appeared to have an unwritten exception for `require`
that doesn't make sense. About 60% of require/include usage
was missing the space and/or had superfluous parentheses.
It is as silly as print("foo") or return("foo"), it works
because keywords have no significance for whitespace between
it and the expression that follows, and since experessions can
be wrapped in parentheses for clarity (e.g. when doing string
concatenation or mathematical operations) the parenthesis
before and after basiclaly just ignored.
Change-Id: I2df2f80b8123714bea7e0771bf94b51ad5bb4b87
Allows update.php to be run when $wgAllowSchemaUpdates = false.
This is useful for non-WMF environments where strict DB permissions
allow database updates (which update.php performs), but no schema
changes (such as adding or dropping tables or indices which update.php
also performs).
It does this by adding the --schema and --noschema flags. Without
either of these flags, update.php will perform exactly as before.
With --noschema, all changes to the table structure or table additions
are skipped. Only data changes are made.
With --schema is used, no schema changes are made to the database, but
the schema changes are saved to a separate SQL file that can be run.
Change-Id: I96b4cfd4c02e9cbf46cc6a0499b87fb3b89020a0
* Moved PopulateRevisionLength/PopulateRevisionSha1 scripts to $postDatabaseUpdateMaintenance
* Fixed bogus "{$prefix}_sha1 != ''" comparison (r94362)
* Removed unneeded NOT NULL check (speeds up script a bit) from populateRevisionSha1 script
* Various code cleanups
