1) The following methods were hard deprecated:
- User::addAutopromoteOnceGroups
- User::getEffectiveGroups
- User::getAutomaticGroups
- User::getFormerGroups
2) User ::getGroups, ::getGroupMemberships, ::addGroup,
::removeGroup were replaced in the production code,
but they were not hard deprecated because of conflict
with UserRightsProxy class.
Bug: T275148
Change-Id: Ia69598316f5dc5dd9511f6112b5b13e1aa07575a
Introduce a new schema migration stage in which rev_actor is used
directly and the revision_actor_temp table is no longer needed. This
becomes the new "new" stage whereas the previous situation is now
termed SCHEMA_COMPAT_TEMP.
Introduce migrateRevisionActorTemp which copies data from
revision_actor_temp to rev_actor. The code is similar to
migrateImageCommentTemp.php except that it doesn't delete from the old
table.
Partial revert of c29909e59f. That change removed direct
references to $wgActorTableSchemaMigrationStage and made queries
involving revision_actor_temp be unconditional. Such changes need to be
reverted to make the use of revision_actor_temp be conditional again.
In ActorMigrationTest, I compacted provideGetJoin() and
provideGetWhere(), removing most of the duplication between expected
values. I gave all the stages a short name, and mostly used the name in
providers.
Bug: T275246
Change-Id: I7498107dd6433ab7de5bf2e7b3fe2aa5e10e345d
In case of the referenced addWiki bug, the following was happening:
1. MWServices were initialized before Setup.php is complete
and before extensions were loaded. Deprecation warning was emitted.
2. onMWServices hook was run, thus hook container was created, but
without any extensions loaded.
3. When global MWServices instance was allowed, and services were
reset, hook container was salvaged. When that happens, already
instantiated handlers are preserved, so onMediaWikiServices handlers
(none at this point) were preserved.
4. GlobalPreferences refefine PreferencesFactory, but it was not
actually redefined, since onMediaWikiServices handler array was
salvaged in 3
5. The rest of the hooks work ok, since they are dynamically initialized
after extensions were loaded.
6. One of the hook handlers, implemented in GlobalPreferences,
expected PreferencesFactory to be redefined, but it was not.
7. Boom!
Bug: T285894
Bug: T275453
Change-Id: I8b16529e93dc12484e3501fab4fd34fca70114ea
For running long-term maintenance scripts, having waitForReplication()
is not enough as that method doesn't count for cross DC-replication and
replication the cloud making issues if kept running more than a couple
of hours. This mitigate the aforementioned problem.
Change-Id: Ifa0b31dde4a57a4d3f2b00c29410be568cfa6b91
* Make the --ns option optional. I don't know why it was required. The
bug affects any page that had its history merged.
* Reorganise the code so that dry run mode just skips the write queries,
making it more obvious what delete mode will do.
* Skip invalid titles.
Bug: T263340
Change-Id: I0dc0d72b254f43ba5ca5b8af45747f9c349c7a15
Results in passing a user where previously the fallback
to $wgUser was being used, mostly in tests.
Bug: T255507
Change-Id: Iabe24315b23c0ad1272353186425e71974528d23
* Add automatic splitting of large metadata on upload or refresh. If
the reserializeMetadata option is enabled, metadata stored with PHP
serialization will be automatically reserialized to JSON.
* Inject configuration variable $wgUpdateCompatibleMetadata via
LocalRepo instead of accessing it directly.
* In refreshImageMetadata.php and rebuildImages.php, construct a new
LocalRepo with config overrides, instead of overwriting config
globals. Add a helper to RepoGroup to help with this.
* In refreshImageMetadata.php, add new options --convert-to-json and
--split which reserialize metadata and optionally split out large
items to blob storage.
Also, refreshImageMetadata.php was totally broken in the non-force mode
since metadata refresh on page view was disabled in b814245d9f. The
maintenance script was relying on newFileFromRow() magically upgrading
the row, which doesn't happen anymore. So, call maybeUpgradeRow()
directly.
Bug: T275268
Change-Id: I7bf7d9cef71641e287ca4346b568b381f4ada50e
Large wiki farms may have to purge servers concurrently (instead of
one at a time) in order to keep up with new writes and delete expired
rows faster than new rows are written.
The parameter for this uses server tags for three reasons:
* Maintenance risk and complexity.
This requires the least information about MW configuration to be
hardcoded in the scheduled maintenance cronjob (compared to: server
indexes which are a runtime concept, or specific hostnames/IP/
tableprefixes which may change and should not require
coordinating changes elsewhere).
* Operational convenience.
By using server tags, the parameters don't have to vary between
data centers.
* Code complexity.
The current code for obtaining connections is based on server indexes,
which are easy to mapped at runtime from server tags. Other ways
of identifying shard like hostnames are either an awkward fit (as
they don't uniquely identify a shard per-se, with multiple instances
on the same hardware at WMF), or require SqlBagOStuff to store and
maintain more information about connections than it currently has
readily available.
Bug: T282761
Change-Id: I618bc1e8ca3008a4dd54778ac24aa5948f27c52e
It's logically part of LoggedUpdateMaintenance. There are two copies
already, and I was considering adding a third.
Change-Id: Ib3686cb3d408a017cd17cde624df71edb379f07e
Updates for the removal of the Revision class itself
and the various methods/hooks/variables removed in the
process, including:
- Update some documentation removing most references
to the Revision class and updating the MCR migration
notes to reflect the past tense for Revision methods.
- Change some capitalization from "Revision" to "revision"
to make it clear comments are about revisions in general,
not the Revision class in particular.
- Minor code tweaks including removing unused variables that
were around for the old hooks that were removed, and
removing the use of DeprecatablePropertyArray where no
longer needed for anything.
- Fix incorrect documentation for PageUpdater::getStatus(),
the status value changed a while ago to have revision-record
in addition to revision, and recently to only have the
revision-record, but ironically PageUpdater was never updated.
- Removed Parser::$mRevisionObject, used to be a Revision object
and was deprecated in 1.35, missed earlier because it was no
longer being set to Revision objects, always null.
- Add RevisionRecord typehints in DummyLinker to match those
in the corresponding Linker methods
This should be a no-op in terms of functionality.
Bug: T247143
Change-Id: I03bbb94fc29085855448780b1a5ad9063911ecc4
This emperical data will help confirm and gain confidence in our
understanding of how much time is spent in the delete operations under
various conditions, and by extent whether it'll be worth converting
the sleep duration logic to an interval that includes the time spent
in the delete operation itself.
Bug: T282761
Change-Id: I0406d9c0807bb9722623f3ec61f1e559dbe14aa9
array_fill_keys() was introduced in PHP 5.2.0 and works like
array_flip() except that it does only one thing (copying keys) instead
of two things (copying keys and values). That makes it faster and more
obvious.
When array_flip() calls were paired, I left them as is, because that
pattern is too cute. I couldn't kill something so cute.
Sometimes it was hard to figure out whether the values in array_flip()
result were used. That's the point of this change. If you use
array_fill_keys(), the intention is obvious.
Change-Id: If8d340a8bc816a15afec37e64f00106ae45e10ed
Image metadata is usually a serialized string representing an array.
Passing the string around internally and having everything unserialize
it is an awkward convention.
Also, many image handlers were reading the file twice: once for
getMetadata() and again for getImageSize(). Often getMetadata()
would actually read the width and height and then throw it away.
So, in filerepo:
* Add File::getMetadataItem(), which promises to allow partial
loading of metadata per my proposal on T275268 in a future commit.
* Add File::getMetadataArray(), which returns the unserialized array.
Some file handlers were returning non-serializable strings from
getMetadata(), so I gave them a legacy array form ['_error' => ...]
* Changed MWFileProps to return the array form of metadata.
* Deprecate the weird File::getImageSize(). It was apparently not
called by anything, but was overridden by UnregisteredLocalFile.
* Wrap serialize/unserialize with File::getMetadataForDb() and
File::loadMetadataFromDb() in preparation for T275268.
In MediaHandler:
* Merged MediaHandler::getImageSize() and MediaHandler::getMetadata()
into getSizeAndMetadata(). Deprecated the old methods.
* Instead of isMetadataValid() we now have isFileMetadataValid(), which
only gets a File object, so it can decide what data it needs to load.
* Simplified getPageDimensions() by having it return false for non-paged
media. It was not called in that case, but was implemented anyway.
In specific handlers:
* Rename DjVuHandler::getUnserializedMetadata() and
extractTreesFromMetadata() for clarity. "Metadata" in these function
names meant an XML string.
* Updated DjVuImage::getImageSize() to provide image sizes in the new
style.
* In ExifBitmapHandler, getRotationForExif() now takes just the
Orientation tag, rather than a serialized string. Also renamed for
clarity.
* In GIFMetadataExtractor, return the width, height and bits per channel
instead of throwing them away. There was some conflation in
decodeBPP() which I picked apart. Refer to GIF89a section 18.
* In JpegMetadataExtractor, process the SOF0/SOF2 segment to extract
bits per channel, width, height and components (channel count). This
is essentially a port of PHP's getimagesize(), so should be bugwards
compatible.
* In PNGMetadataExtractor, return the width and height, which were
previously assigned to unused local variables. I verified the
implementation by referring to the specification.
* In SvgHandler, retain the version validation from unpackMetadata(),
but rename the function since it now takes an array as input.
In tests:
* In ExifBitmapTest, refactored some tests by using a provider.
* In GIFHandlerTest and PNGHandlerTest, I removed the tests in which
getMetadata() returns null, since it doesn't make sense when ported to
getMetadataArray(). I added tests for empty arrays instead.
* In tests, I retained serialization of input data since I figure it's
useful to confirm that existing database rows will continue to be read
correctly. I removed serialization of expected values, replacing them
with plain data.
* In tests, I replaced access to private class constants like
BROKEN_FILE with string literals, since stability is essential. If
the class constant changes, the test should fail.
Elsewhere:
* In maintenance/refreshImageMetadata.php, I removed the check for
shrinking image metadata, since it's not easy to implement and is
not future compatible. Image metadata is expected to shrink in
future.
Bug: T275268
Change-Id: I039785d5b6439d71dcc21dcb972177dba5c3a67d
This can be useful for running in discrete batches, or running on
user cohorts by registration date.
Bug: T283867
Change-Id: I9ff593f4d9a98a2069df977b75e505ac9e4abb5d
This class is not stable to extend, nor does codesearch reveal
any classes extending it outside of core, so we can just evaluate
if $wgUser needs to be set for this class and subclasses in core.
TableCleanup is not set up to be run directly, it requires that it
be subclassed and the subclass run as a maintenance script. Within
TableCleanup itself, nothing depends on $wgUser. Looking at the
subclasses in core:
* CleanupCaps overrides the execute method, so the code to set
$wgUser in TableCleanup::execute() is not being run
* CleanupImages, TitleCleanup, and ClenupWatchlist do not
appear to have any code that relies on anything related to the
current user or context
Since nothing is using the user in any form, simply remove the
write to $wgUser, no need to replace it with setting the context
user
Bug: T243708
Change-Id: I1a22f2ebab028822e663ab1fdcbd6c7b02331fef
This reverts commit ecf826a2ee.
Reason for revert: need to edit the patch and then it will be GTG in order to finish hard deprecating of User ::getCanonicalName, ::isUsableName, ::isCreatableName
Change-Id: I2f57f56728fcbeada96dc2228f07dc8bcaa5d4f6
For MySQL/Sqlite:
- Nothing
For Postgres:
- Introduce the table. It's not used but it'll be used in the future (T220450)
Bug: T164898
Bug: T230428
Bug: T220450
Change-Id: I9f33132676344f8cd813f7a438b3a6a078fd281c
In a few places where a PermissionManager is used
but only GroupPermissionsLookup is needed
Also update references to the class in PermissionManager
that referred to it as GroupPermissionLookup
Change-Id: I5d7a13900852a38768a106aeee1ce012c3a04ea2
This patch injects services into WikiImporter. It also adds
a WikiImporterFactory service for creating WikiImporter
instances.
Change-Id: I2966297e5728fca1ae8280361f1008cef6c6041b
Postgres:
- Drop foreign key from rev_page
- Make rev_page not nullable
- Change rev_comment_id from int to bigint
- Change rev_actor from int to bigint
- Sync rev_page_id index with MySQL
MySQL/SQlite:
- Drop default from rev_timestamp
Additional changes in the generator script to handle more
formatting issues due to use of additional custom table options
Bug: T230428
Bug: T164898
Change-Id: Ia07dd52e43123473a1728523a3f863280537db8e
Also added token and flags fields. The token field can
be used as a tie-breaker for modtime and also for faster
cas() operations. The flags field makes serialization and
compression format changes easier in the future.
Bug: T274174
Change-Id: I45731a877b21835652993c2d285165a76eeae3e9
These are rows in page_table that have 'page_latest' entry with
corresponding 'rev_id' but no associated 'rev_page' entry in revision
table. Such rows create ghost pages because their 'page_latest' rev is
actually missing or moved to a different page now (which possess the -
associated 'rev_page' on revision table now).
https://en.wikipedia.org/wiki/Module:Jct/city/Chinissai
(page_id=41871839) is an example of such pages. Its page_latest rev is
819371998. But this revision has been moved to another page now
(page_id= 56252475), rendering the former inaccessible.
fb58d39 will prevent this going forward (for scribunto content), but we
need to clear the extant pages for module namespace and others caused
by something else.
Bug: T263340
Change-Id: I51abc295e37030ab181d4380f62c30d7998f1b9e
It's causing issues in the drift reports. Can be fixed there instead but
we shouldn't have this extra space anyway.
Change-Id: I29a8e093ae0a6d8948a61c197b017a54c6f577ea
* There was a carriage return, as part of a self-overwriting progress
bar. While nice for humans running the script by hand, this made
the script difficult to understand in WMF production where the logs
go to syslog/journalctl, which doesn't like \r and thus showed only
`[2KB blob]` instead of the actual output. This can bypassed with
`journalctl -u … --all`, but that still leaves one with a sea of
misaligned progress bars, concatenated as one long "line".
It seems most of our maintenance scripts nowadays just keep printing
lines to notify of progress made, so change the script to that,
by just printing a boring "... % done\n" line (at most) every 0.1%.
* Change hardcoded batch size of 100 to use $wgUpdateRowsPerQuery.
This is generally a no-op as this configuration defaults to 100 in
DefaultSettings.php, and is not overridden in WMF production.
* Add a "--dry-run" option to allow for last-minute verification of
the age and date calculation which is rather non-trivial given that
we don't index creation time and assume $wgParserCacheExpireTime
is constant and unchanged, which in practice, when this script is
considered for running, tends not to be the case, making it hard to
be sure exactly what it will do.
Minor stuff:
* Make the ORDER BY clause explicitly use ascending order.
* Try to retroactively document why we use a --msleep parameter
instead of waiting for replication.
* Revert some of the variable name changes of I723e6377c26750ff9
which imho made the code harder to understand.
* Flip order of $overallRatio additions to match the order of
$tablesDoneRatio (e.g. high level + current thing).
* Remove use of Language->timeanddate() in favour of native
date formatting, mainly to include seconds and timezone,
but also because its simpler not to bring in all of Language
and LocalisationCache into the script.
* Pass unix time directly to SqlBagOStuff::deleteObjectsExpiringBefore,
as other callers do, instead of TS_MW-formatting first. There is
also additional casting to TS_UNIX within the method.
Before:
> Deleting objects expiring before 21:43, 7 May 2021
> [**************************************************] 100.00%
> Done
After:
> Deleting objects expiring before Fri, 07 May 2021 21:43:52 GMT
> ... 50.0% done
> ... 100.0% done
> Done
Bug: T280605
Bug: T282761
Change-Id: I563886be0b3aeb187c274c0de4549374e0ff18f0
Mistake during the abstraction (Ibdaf332ea1d)
It doesn't need schema change since 1.36 is not released yet.
Bug: T230428
Change-Id: I071c39dfadf185b01e9109085907d6e3deb1f02f
Make getServer() always return a string, as documented, even with new
Database::NEW_UNCONNECTED handles that have yet to call open(). If the
'host' parameter to __construct() is ''/null, getServer() now returns
'localhost' instead of null. This avoids problems like fatal errors in
calls to TransactionProfiler::recordConnection().
Use Database constants for "connectionParams" field keys for better
static analysis.
Also:
* Add Database::getServerName() method that returns "readable" server
names in the style of LoadBalancer::getServerName(). Note that the
"hostName" field is already passed in from LoadBalancer.
* Migrate most getServer() callers to getServerName() for easier
debugging and more readable logging.
* Also, normalize Database/LoadBalancer SPI logging context to use
"db_server" and reduce logging code duplication in LoadBalancer.
Bug: T277056
Change-Id: I00ed4049ebb45edab1ea07561c47e226a423ea3b
The user 'Maintenance script' is often used to perform various
automated tasks. Providing it everywhere as a string literal is
error-prone, and errors can be somewhat disruptive (e.g. with
User::newSystemUser with steal=true it can erase the credentials
of a legitimate account). Provide a constant instead.
Also replace existing uses for consistency.
Change-Id: I685a5bfe56bbf1a47f35072f7f7c8be320ee27db
This logic is not needed to run on every PHP process and was making
it difficult to run offline maintenance scripts without additional
complexity based on Maintenance::getDbType and DB_NONE.
Instead of skipping this only for DB_NONE, and establishing a pattern
that may spread to other ad-hoc places throughout the codebase, instead
remove this entirely from the eager set up code for all PHP processes
and move it to the service wiring and dependency injection.
That way, it naturally doesn't happen until and unless the DB service
is actually called upon. Scripts and entry point that need to disable
the DB service, can continue to use
MediaWikiServices::disableStorageBackend.
== Impact on SiteStatsUpdate ==
With wgCommandLineMode no longer being read at run-time from a global,
but in service wiring, this means SiteStatsUpdateTest can't change
the behaviour between CLI-like and Web-like, unless it e.g. resets
the 'DBLoadBalancerFactory' service first. Unfortunately, while most
any reset is supported, a reset of the 'DBLoadBalancerFactory' would
be unsupported as that would lose the temporary db clone context and
such, bringing us to either the developer's live db, or a broken set
up altogether. If there is a strong need for toggling oppertunistic
updates off and on at run-time, this could be supported in the
DeferredUpdates class perhaps, but we already have numerous methods
there (incl db begin/commit being a good proxy already), which this
test already used, so for now I've just removed the extra assertion
for this as it wasn't essential to that test.
Bug: T228895
Bug: T238436
Change-Id: Icf29bc484c155f52b6d8f61e5902233a15ba0c6d
Postgres:
- Rename the table from `mwuser` to `user`
- Transition user_id from int to serial
- Make user_token not nullable and add default
- Make user_real_name not nullable and add default
- Make user_email not nullable
- Make user_newpassword not nullable
- Make user_password not nullable
- Drop UNIQUE contraint on user_name and add default
MySQL/SQLite:
* No changes
Bug: T164898
Bug: T230428
Change-Id: I746714f7b3ae16f9625f97bcca84280fcd8b61a0
As of 99d4ad5995, mw.log.deprecate is no longer used within the
startup module, and I don't expect use of it to return. The only
reason we needed it in startup was because mw.config, which was a hybrid
that is both deprecated (when accessed via window) and not deprecated
(when accessed via mw.config).
For anything else, there is no reason to ever ship deprecated code
in the startup module that isn't internally used by mw.loader.
Even if an mw.loader method were to be deprecated at some point, we'd
remove it from startup and ship it in mediawiki.base instead and
deprecate it there (like '$j' and 'importScript', for example).
For future reference, this move was made possible by preparations in
Ied4d08c554936 and I68f2021fd39b.
Change-Id: I2ef8d4e6c3c32a811d418d48bf2b0da9f3d621b1
Currently all the signal constants emit warnings as they are undefined
in PHP 7.4 and throw fatal error in PHP 8, if pcntl is not available.
pcntl extension is not enabled by default, and is not required by
MediaWiki, so this class should throw a better error if it's not
found. The class already has comment that pcntl and posix are required
but this is meaningless since the error and a warning for each constant
would be emitted anyway.
https://www.php.net/manual/en/pcntl.installation.php
Convert RESTARTABLE_SIGNALS constant back to static property as it was,
because we can only use these constants after confirming they exist,
which happens in the constructor.
Bug: T280456
Change-Id: I66deaa9b346b936b2628ac0511492d20a42fea6c
Use case: for a list of classes used in a specific context such as
MediaWikiServices, list all files containing these classes, so they can
be processed with command line tools such as grep.
Change-Id: I88dbee72dc5a560624f8cc1da0d905460309f624
* Remove LOCK TABLES. It was probably never necessary, but in any case
we have transactions now.
* Delete updateDoubleWidthSearch.php, it was for upgrading from 1.17 or
earlier, which is no longer supported. Revert the move of various
updateSearchIndex.php functions to Maintenance. Nothing has ever used
these except updateSearchIndex.php and updateDoubleWidthSearch.php.
* Convert the query to use the new Database:select() method.
* Remove migration from searchUpdate.pos to searchUpdate.wiki.pos, which
was put there to support upgrades to 1.16.
Bug: T252853
Change-Id: I19bb44a9a46c2ebdb16a777bb462375278b05b7b
* Revisions always have an associated actor, which will be present in
the rev_actor alias that comes from ActorMigration, so just use that
actor instead of doing a complicated thing involving
User::newFromAnyId()
* Stop using ActorMigration for logging and recentchanges, no longer
necessary.
* The code to fill rc_bot and rc_patrol used an almost identical query
which joins recentchanges with user_groups. So I factored that out to
findRcIdsWithGroups(). The update code for the two cases was somewhat
different, but I preferred the rc_bot one with its array_chunk() call,
so I used that style of update also in the rc_patrolled case.
Bug: T278917
Change-Id: I32acb5848eacd4b28c0f89e8a6ec686304744c5b
== Adding --skip-message-purge
Follows-up d91c6627a9. Per CR and Phab comments, I don't think we
can (yet) promise a generic "--offline" mode. This seems too easy to
misuse. Both for users of the script, as well as for future development
to the script. It can fall out out of sync with requirements of the
overall system and leaves no natural place to discover what
responsibilities are being deferred and how the operator should fulfill
those duties.
We know LCStoreDB doesn't work offline, but there are likely other
aspects of this that don't yet work offline for some users. It would
require a much more rigorous refactor (and dropping signifant extension
hooks) to make this reliably offline. I'd welcome a standalone script
using only vendor libs, that does nothing other than scan directories
and build JSON/PHP/CDB files, but that's not what it is today.
What we can do is skip the one operation we know requires a live
DB connection, and (my main motivation for this commit) then document
that skipping it, require the user to perform the purge by other means
instead, since the purge itself is not actually optional.
Also, make this not a WMF-specific option in MW core, by committing
the accompanying script needed for this to work. This was previously
in the WikimediaMaintenance extension as "refreshMessageBlobs.php".
== Keeping --offline (as --no-database)
As far as I know, the purge is the only action we ran into that needed
a database connection, and important to note was that it's not optional.
I think for WMF we did not run into any other logic in our configuration
that uses a database, so --skip-message-purge should suffice. However,
I've kept the option for two reasons:
1. To recognise in some way the business need for WMF to use this
script in an offline manner, and thus document that the script
should at least have a way to work offline, even if there may be
site configurations and extensions that make this impossible, from
a core perspective we want to (experimentally) try to support this.
2. There is unimportant setup logic that happens in doMaintenance.php
where the service wiring for LBFactory is activated by default.
This seems avoidable and technical debt, but at least for now
we do need a way to skip that, so this option will continue to
have that effect.
However, I've renamed the option and inverted its promise. This is not
a promise from core *to* the user to offer an offline mode. Rather,
it is a promise *from* the user that they think nothing DB-needy is in
use.
Bug: T268698
Bug: T263872
Change-Id: I7878fdf4a901fb5e75da540293bb9df9fb508c20
Adding it (only to be removed later) is not useful and interferes with
the internals of the schema builder because it masks the actual table
name during the table sql building and at some stages, this actual name
is required to be known
Bug: T191231
Change-Id: I57cc9b83c81f5c2d0d50c7b9e0dc334e7251c74f
This partially reverts commit 1d9f3542bd.
Reason for revert: cannot use methods that might trigger class
loading in Maintenance::showHelp, as it's called on parameter parsing
errors which happen before Setup.php is run.
Change-Id: I0ffb2800a007d4077d7f33bc8cdef1d895d1ab5f
This patch was introduced in r1030 (2002) and was never
wired to update.php and any mention of it was removed from documentation
in r23242 (2007). Since then, you can't find any mention of this file.
It clearly won't run on any modern mediawiki database.
Change-Id: I49a7a0bd53d5fb1b97f9c7016bb72d29e50211f7
Currently both email and real name are documented as
non-nullable, but it seems there's code that breaks
this contract. Try stricter type checks.
Depends-On: Ie8fa1e7881e1b016dccdc9097a1763a07cc140b9
Depends-On: Id3bf35fe56c459597ed6a602bdf6ca4860271f6e
Change-Id: I2f4b7b3500a2b25f7d5cf25147f65ad412d61955
The query does a LEFT JOIN between user and actor. Given the state of
the actor table migration, it's impossible for a user to be active
without having an actor row. So such users must be inactive.
isInactiveAccount() does a loop over tables, sending them all to
ActorMigration, but that's obsolete for all except revision. So split
out the revision case out of the loop, with roughly the same code as
before. Inside the loop, do new-style queries in the knowledge that the
*_actor fields exist.
logging still needs a special case, but like the other non-revision
tables, it no longer needs ActorMigration.
Bug: T278917
Change-Id: I37281a0c856618674160bb39506108d5fff92479
This was introduced in r103367 as a follow up to r103365 while none of
the commits wire this to update.php and since then it has been unused.
And even if it was wired dynamically somehow that I missed, it's not
needed anymore as we don't support direct upgrades from these versions
(1.18 and 1.19) anymore.
Change-Id: I1e16de398bbe61adcb55787117378ea96a2b3e9f
Split off to make the migration patch smaller
Postgres:
- Make user_touched not nullable
MySQL/SQlite
- Change user_name from varchar to varbinary
- Change user_name from varchar to varbinary
- Drop empty string default from user_touched (Timestamp field)
Bug: T230428
Bug: T164898
Change-Id: I8fe0b1fb2af3149a2e2fdae7bb056ac6f863b09c
Probably nobody is using these.
Also hopefully after fully migrating to abstract schema, there'd
not be any more unnecessary drifts between MySQL and Postgres tables,
obsoleting the need for compare_schema.pl
For mysql2postgres.pl, dumpBackup.php/importDump.php can be used.
Bug: T258876
Change-Id: Ief36bca6f3a387f811408f2a5e4840656dfffff2
This patch was introduced in r1161 (February 2003) but it wasn't
mentioned in the patch-list.txt and checking git history since initial
version (phase3) didn't return any mention of it since then.
It clearly can't be ran on any modern mediawiki setup.
Change-Id: Ic5a8f0699dd31a181c31582be4958522ce3483b3
There's no reason to keep schema change that's no longer useful.
History is already tracked by git.
Change-Id: Ia8aa0d21ae5f2d799d9a641ebe7b924f56e07ab1
This update is not being called in basically any wiki because it skips
when interwiki exists and that table was introduced in 1.2 (we don't
support direct upgrade from 1.26 or earlier).
The .sql file is not useful but installers use interwiki.list and that
is useful.
Bug: T272199
Bug: T273080
Change-Id: I0de40b8dc60eb07b9c7ebeb620142f3cdfe5b67b
- doCategoryPopulation is not needed nor being called anymore. There's
not much use for the maintenance script either.
- doPopulateParentId ditto.
Bug: T272199
Change-Id: Id7fc111b71e8ee9a37a3e2e56849ac5afeea9f9d
These are from versions we don't support direct upgrade anymore and they
are already removed from update.php wiring.
Bug: T272199
Change-Id: I863d91d7d620943571cb8bb22f663c2efbbd0821
These changes to tsearch functions were introduced in 2010 in a version
that we definitely don't support direct upgrades from.
Bug: T272199
Change-Id: I47c4054552daad55c0e13eec36865706ee6d1903
Added new index: 'rev_page_timestamp' (the corresponding index
in MySQL is currently 'page_timestamp' but it will soon be
renamed to have the rev_ suffix as part of T270033).
Rename rev_timestamp_idx and revision_unique to match names
that are in use for MySQL
Bug: T230428
Bug: T164898
Change-Id: I3a79a892673b073cea57ee4e397b2963c7cef2f1
Postgres:
- Change page_namespace from smallint to int
- Change page_random from numeric with arbitrary precision to float
- Make page_touched not nullable
MySQL/SQLite:
- Change datatype of page_title from varchar (with binary collation)
to varbinary(255)
- Drop default empty string from timestamp field of page_touched
Bug: T230428
Bug: T164898
Change-Id: Ibdaf332ea1da309d31d35a6ebbc1b8fefced335e
Subclass DBAL\Platforms\MySqlPlatform so that we can override
methods cleanly. Move the current MySQL hack from the schema
generator script to this class.
If 'float' is specified in the json spec without any option, the
FLOAT data type will be used. To use DOUBLE PRECISION (aka REAL)
a 'doublePrecision' option has to be specified and set to true.
No support for specifying arbitrary precision since no current
table is using that and the feature is deprecated in MySQL 8 anyway
Due to T270740, the subclassing is not straightforward because
the base DBAL MySqlPlatform class is renamed in DBAL 3.0.0. For
now a compatibility intermediate class is used as in PG subclass
Other changes: Use switch instead of if/else and remove brackets
in instantiating a class without arguments.
Bug: T191231
Change-Id: I9a5087b1e2afc2b63e30d67ea2ca616f047a0258
This function was removed in abstracting interwiki table (Id652cb544)
and it's not needed anymore.
Change-Id: Ifc956ae91f8362e9872cd449fcab5cfb4870ec7f
