Notable changes:
* In SqlBagOStuff::getConnectionFromServerInfo, only two loggers were
injected. The rest implicitly got a NullLogger due to being absent.
These are now effectively unsilenced.
* Database::__construct() required almost all parameters, even the
loggers. I've wanted to move some of DatabaseFactory into the ctor
here for a while. In order to make this change not a breaking
change, the new 'logger' parameter is optional with NullLogger as
default. This allowed some of the test cases, which were simply
passing NullLogger, to be fixed by passing nothing instead of
passing the new option name.
The Database class is behind a dozen layers of indirection for
real use, so this will still be injected just fine (DBF, LB, LBF,
MWLBF, etc.).
* In LegacyLogger, the handling for $wgDBerrorLog was previously
limited to DBConnection and DBQuery. This now includes errors
from other (generally, newer) parts of Rdbms as well, which were
previously missing.
This only affects sites (typically CI and dev setup) where
$wgDBerrorLog is used, as opposed to the more common
$wgDebugLogGroups by-channel configuration.
* TransactionProfiler gets its logger injected in a rather odd way,
via entrypoints (MediaWiki.php, ApiMain.php, and MaintenanceRunner)
as opposed to service wiring. This is kept as-is for now.
* In LBFactoryTest, in particular testInvalidSelectDBIndependent2,
there are cases that intentionally produce failures of which
the result is then observed. In CI we assert that dberror.log is
empty so instead of adding the missing logger fields to that
LBFactory instance, the only one set (replLogger) is removed.
The alternative is to set 'logger' now, which would naturally
cause CI failures due to unexpected entries coming through to
non-mocked error log.
Bug: T320873
Change-Id: I7ca996618e41b93f488cb5c4de82000bb36e0dd3
The day has gone. Still keeping the code as the schema changes are not
done in production but the data migration has been finished.
Bug: T299417
Change-Id: I906e069a63d1dae14924c72318b22b16244371d6
This is a quick find & replace of calls to the deprecated method
ParserOptions::newCanonical() when the context is the string literal
'canonical'. This can be safely replaced by called newFromAnon().
Change-Id: If7bb68459b11e0c5f5de188f10fdae85ad1a78bf
When fetching a key from an array, PHP converts numeric strings to
integers. This led to an incorrect category update query.
So:
* In LinksTable subclasses, cast all string-like array keys to string.
* Add a unit test which confirms that no integers leak into link IDs.
* Add a fully integrated regression test for T301433.
The integration test and 7 of the link ID cases are confirmed to fail
if Amir's patch is reverted.
Bug: T301433
Change-Id: I8d19443607121b3efcafb82096bcff18c41035df
* In PagePropsTable, compare values after converting to string. In the
old code this was implicitly done by array_diff_assoc().
* Also convert to string before inserting, since
ParserOutput::setPageProperty() is documented as allowing null, but
the field is not nullable, so the query failed.
* Add a regression test which confirms that no write queries are done on
the second invocation of LinksUpdate.
Bug: T299662
Change-Id: I3f7d5800bf27a47cb57be80bdba13792fe3caae6
Running cat_pages + 1 and cat_pages - 1 for the same rows/categories is
uneeded.
Cannot skip the whole update on move, because by use of parser functions
there could be new categories after cross namespace page moves.
Follow-Up: Ifaa4051a736b01cda82fbd890325e0751ce041f8
Change-Id: I188d0224f1a1d43746f657159e0ed8c80b8646cd
Since LinksUpdate was already run after a page move, it was just a
matter of propagating a move flag down to it, and resolving the
differences between the move case and the edit case.
This should be faster since it avoids writing to the links tables twice
on a page move.
Change-Id: Ifaa4051a736b01cda82fbd890325e0751ce041f8
* In LinksUpdate, put each table in its own class, so that the
special code for each table has a more elegant place to go.
* Use generators to abstract and flatten out the underlying ParserOutput
data structures, without requiring the data to be copied. This allows
the incremental logic which was previously duplicated for each table,
i.e. computing insertions and deletions from the old and new state,
to be factored out. The per-table batch classes act as container
abstractions for the underlying data.
Bug: T263437
Depends-On: I472f4a023969bfde6298eb56112c16d2ae842199
Change-Id: Id40be19a8caa7b4669911927964cfd6755c25238
Each table at least needs an added, deleted and unmodified link in order
to fully exercise the incremental update code.
Disable INSERT IGNORE during testing, since this can hide an omitted
delete query.
Change-Id: Iaa9f32ea5171da4f983379d7ff313bfdf1cb0b2f
The ::getProperty() naming is too generic and doesn't clearly indicate
that these are "page properties" (which have their own table in the DB).
As part of refactoring a clean API out of ParserOutput which can be used
by Parsoid, clean up the naming here.
Soft-deprecation in this patch, there are a handful of external users
which need to be cleaned up before we hard-deprecate.
Bug: T287216
Change-Id: Ie963eea5aa0f0e984ced7c4dfa0fd65d57313cfa
Results in passing a user where previously the fallback
to $wgUser was being used, mostly in tests.
Bug: T255507
Change-Id: Iabe24315b23c0ad1272353186425e71974528d23
This is no longer useful. The schema update it supports
has been removed: patch-pp_sortkey.sql/(I76b4235)
Bug: T273978
Change-Id: Ida469a5401f98a028b7a69242105dc1595af3613
Sometimes, an edit is done with a Title object that has gone
out of sync with the database after a page move. In this case,
we should re-load the current page ID from the database,
instead of failing the update hard.
Bug: T246720
Bug: T204793
Bug: T221763
Bug: T225366
Change-Id: If7701205ec2bf4d4495349d3e67cf53d32ee8357
Add public, protected or private to function missing a visibility
Enable the tests folder for the phpcs sniff
Change-Id: Ibefce76ea9984c47e08c94889ea2eafca7565e2c
knowing if recursion is enabled might help extensions implementing
LinksUpdate hooks to take some decisions.
E.g. CirrusSearch would like to know if a particular update needs to go to a
priorized queue or not (template transclusion).
Change-Id: I0a0de0d4621ed302b4fb550a1ddecd4ac8c5775a
This removes most of the pre-CommentStore text columns, and the
$wgCommentTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_comment remains in the code, as on Wikimedia wikis the revision
table is too large to alter at this time. A future change will combine
that with the removal of rev_user_text, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
CommentStore's constructor continues to take a $stage parameter, and
continues to have the logic for handling it, for the benefit of
extensions that might need their own migration process.
Bug: T166733
Change-Id: I1479c73774e01ead1490adf6128f820c09bce9d4
* ParserOptions is reorganized so it knows all the options and their
defaults, and can report whether the non-key options are at their
defaults.
* Definition of the "canonical" ParserOptions (which is unfortunately
different from the "default" ParserOptions) is moved from
ContentHandler to ParserOptions.
* WikiPage uses this to throw an exception if it's asked to cache
with options that aren't used in the cache key.
* ParserCache gets some temporary code to try to avoid a massive cache
stampede on upgrade.
Bug: T110269
Change-Id: I7fb9ffca96e6bd04db44d2d5f2509ec96ad9371f
Depends-On: I4070a8f51927121f690469716625db4a1064dea5
Providing the perfectly correct number of pages
that have acctually been added to or removed from a
category is extermly hard.
Rather than providing data that is most likely wrong
and a bit useless ONLY provide a link to Special:WhatLinksHere.
This touches on the following bugs and may mean that
some of them don't need to be thought about any further.
Bug: T126855
Bug: T126407
Bug: T126139
Change-Id: Ida06d822d1955091595c17c9c6c2968a40a93bcd
This link could probably also include
&hidelinks=1&hideredirs=1 options
at a later stage
Bug: T119712
Change-Id: I578d550d25d92e20360bcaaf5392ef75a868a483
This reduces the runtime of database-bound tests by about 40%
(on my system, from 4:55 to 2:47; results from Jenkins are
inconclusive).
The basic idea is to call addCoreDBData() only once, and have
a addDBDataOnce() that is called once per test class, not for
every test method lie addDBData() is. Most tests could be
trivially be changed to implement addDBDataOnce() instead of
addDBData(). The ones for which this did not work immediately
were left out for now. A closer look at the tests that still
implement addDBData() may reveal additional potential for
improvement.
TODO: Once this is merged, try to change addDBData() to
addDBDataOnce() where possible in extensions.
Change-Id: Iec4ed4c8419fb4ad87e6710de808863ede9998b7
Some tests fails on wikis with $wgLanguageCode not = 'en', fix this by
setting the correct language context.
Change-Id: Ia72017df59d8beb5c508832584b2431ffab0f77f
* Recursive link updates no longer mention an category changes.
It's hard to avoid either duplicate mentioning of changes or
confusing explicit and automatic category changes.
* LinksUpdate no longer handles this logic, but rather WikiPage
decides to spawn this update when needed in doEditUpdates().
* Fix race conditions with calculating category deltas. Do not
rely on the link tables for the read used to determine these
writes, as they may be out-of-date due to slave lag. Using the
master would still not be good enough since that would assume
FIFO and serialized job execution, which is not garaunteed.
Use the parser output of the relevant revisions to determine
the RC rows. If 3 users quickly edit a page's categories, the
old way could misattribute who actually changed what.
* Make sure RC rows are inserted in an order that matches that
of the corresponding revisions.
* Better avoid mentioning time-based (parser functions) category
changes so they don't get attributed to the next editor.
* Also wait for slaves between RC row insertions if there where
many category changes (it theory it could well over 10K rows).
* Using a separate job better separates concerns as LinksUpdate
should not have to care about recent changes updates.
* Added more docs to $wgRCWatchCategoryMembership.
Bug: T95501
Change-Id: I5863e7d7483a4fd1fa633597af66a0088ace4c68
This is part of a chain that reverts:
e412ff5ecc.
NOTE:
- The feature is disabled by default
- User settings default to hiding changes
- T109707 Touching a file on wikisource adds and
removes it from a category... Even when page
has no changes.... WTF? See linked issue,
marked as stalled with a possible way forward
for this patch.
@see https://gerrit.wikimedia.org/r/#/c/235467/
Changes since version 1:
- T109604 - Page names in comment are no longer
url encoded / have _'s
- T109638 & T110338 - Reserved username now used
when we can't determine a username for the change
(we could perhaps set the user and id to be blank
in the RC table, but who knows what this might do)
- T109688 - History links are now disabled in RC....
(could be fine for the introduction and worked
on more in the future)
- Categorization changes are now always patrolled
- Touching on T109672 in this change emails will never
be sent regarding categorization changes. (this
can of course be changed in a followup)
- Added $wgRCWatchCategoryMembership defaulting to true
for enabling / disabling the feature
- T109700 - for cases when no revision was retrieved
for a category change set the bot flag to true.
This means all changes caused by parser functions
& Lua will be marked as bot, as will changes that
cant find their revision due to slave lag..
Bug: T9148
Bug: T109604
Bug: T109638
Bug: T109688
Bug: T109700
Bug: T110338
Bug: T110340
Change-Id: I51c2c1254de862f24a26ef9dbbf027c6c83e9063
