Quotes started being added to integers in r4984 (August 2004). Before
that, is_numeric() was used to determine whether to add quotes, so
quotes were omitted from numeric strings, which is obviously wrong.
The idea here is to use the type of the variable to hint to the database
as to whether quotes are needed. The results are somewhat inconsistent,
since some callers do not convert numeric strings obtained from user
input to integers. That makes it a more conservative change. Callers can
opt out of unquoted integers by casting them to string.
The reason for doing this is that quoting integers turns out to be not
as harmless as originally assumed. We found a case of it confusing the
MariaDB query planner, causing inappropriate indexes to be used.
I also made addQuotes() consistently return a string, instead of
returning an integer for boolean values. This was already the case for
MySQL, but it seems like a good idea everywhere.
Bug: T238378
Change-Id: I70473280f542ee5ecd79e187f580807410fbd548
The WikiPage::doUpdateRestrictions() method is responsible for updating
the page_restrictions table when protection settings are modified for a
given page. Currently, it unconditionally issues a query to delete existing
rows associated with the page being modified - using the page ID reference
stored in the table's pr_page field - even if such rows may not exist.
On MySQL and derivatives, this statement will create a gap lock if no rows
were found.
This can cause a deadlock if another thread then attempts to manipulate
protection settings for a different page ID that falls into the same gap.
The contending thread will likewise issue a query to delete existing
protection rows for the other page ID, which will create a gap lock on the
same page ID gap. At this point, neither thread can proceed with inserting new
protection settings for their respective pages due to the gap lock held
by the other, and a deadlock occurs. Report details in T214035 indicate that
this error condition can be observed when running mass protection scripts
operating on user and user talk pages.
This patch aims to reduce locking by first querying for existing rows in the
page_restrictions table associated with the page ID whose protection settings
are being changed, then deleting those rows based on their autoincrement pr_id
primary key value. This will not attempt to delete rows that do not exist,
thereby avoiding a gap lock.[1]
---
[1] https://dev.mysql.com/doc/refman/8.0/en/innodb-locks-set.html
Bug: T214035
Change-Id: Id796df6263362839bfe80b32d5e0582dbd5db9bb
This is very similar to I53a7ed59 (T223151). In that bug it was choosing
the `times` index when it should have used `actor_time` due to a
non-empty performer. This time it's choosing `times` when it should be
using `type_time` due to a non-empty set of types being queried.
Bug: T237026
Change-Id: I02c77dde6b5b54d7bea801135051b006d39459b0
Introduce a more specific message for when the number of selected items
exceeds the maximum number allowed.
Change-Id: I359b65ac397b4acef32940ff8ff9af33651f7a7b
Using @see is not enough description
Enable the php sniffs for now, but skip /tests/ to fix it later.
That avoids new issues in future patch sets
Change-Id: I49cb341a2880bfaeefb6bbfbb1717051ea3a4b16
The maintenance script might be run to clean up users with no ID in the
`revision` table even after the other tables have had the ID and name
fields removed (in favor of the actor ID fields). Handle this situation
so as to not error out.
Bug: T238043
Change-Id: Ie84dab4218d816106bf4b0e61f020148730220f0
I find the word "name" very much ambiguous. Here it means "file name
without extension".
I checked and found these methods are suprisingly often used by accident,
in cases where stripping an arbitrary substring from titles that contain
one or more dots would actually lead to errors. A much better name for
the method would be getNameWithoutExtension(). This would prevent such
mistakes from happening, but would be a breaking change. For now, I
suggest to update the documentation to make the difference in behavior
much more obvious.
Change-Id: Iecda9e51841b8570468f691376e3b44c272f79eb
The contributions and history page was showing some semicolons in unexpected places.
These unwanted semicolons are now supressed by reverting to a new standalone element
in exactly the same place as the previous semicolon. This avoids the issue of
ordering that we hit before.
I have documented the behaviour of the semicolon separator in contribpager pages
My seemingly harmless change in Ic4508788299a13c4c830f447141d17d99ebe002e
For future generations I have encapsulated what I've learned in extensive
comments which seem important given the information I have acquired while
working on this patch.
Bug: T233649
Change-Id: I9723ead1815685a9cbcccf2c4e2f3ffff36dcee3
Currently apihelp doesn't mention that if you query information
about revisions, e.g a user that made a certain revision,
the response will be "userhidden". This commit includes that information
in modules API:Revisions, API:AllRevisions, API:DeletedRevisions,
API:RecentChanges, API:UserContribs, API:Watchlist, API:ImageInfo
and API:Compare.
Bug: T186573
Change-Id: I579f0d8c8183d5b158b9d3c9d6ae58e99984e58c
* For some reason, deletion didn't go beyond the first batch in
beta. Simplifying the check, removing the reliance on affectedRows().
* If the last deletions were the same number as the batch size, the
script went for the second loop, feeding an empty array of IDs to
delete(), causing an exception.
Change-Id: Id793aeef0517041a0216110abd8b64ec85deff1e
