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
Fixes the following error message when updating from an older database.
Renaming index il_from into PRIMARY to table imagelinks ...[7dbf1dd298ecf39128707744] [no req] Wikimedia\Rdbms\DBQueryError from line 1149 of /home/zok/mediawiki-1.30.1/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?
Query: INSERT INTO imagelinks_tmp
SELECT * FROM imagelinks
Function: Wikimedia\Rdbms\Database::sourceFile( /home/zok/mediawiki-1.30.1/maintenance/sqlite/archives/patch-imagelinks-fix-pk.sql )
Error: 19 UNIQUE constraint failed: imagelinks_tmp.il_from, imagelinks_tmp.il_to
Explanation:
the "imagelinks" table used to have two fields: il_from and il_to.
At one point during the development of mediawiki a new field has been
added called il_from_namespace. This new filed is the second column
if the database is created from scratch, however if the database is
updated from an older version then the il_from_namespace column becomes
the 3rd column.
That means that some of the older databases will have the columns in the
following order:
(1) il_from, il_from_namespace, il_to
while some older ones, which have been updated will have the following
order:
(2) il_from, il_to, il_from_namespace
This shouldn't matter much, except the file modified in this commit
copies records from one table to another using the INSERT INTO ... SELECT
command without explicitly listing the column names.
The newly created table has the (1) order, but the source table
might sometimes have the (2) order.
Explicitly listing the column names solves all the issues.
Change-Id: I222b171495d14ae45339c4679e263f0ab610e826
On a fresh install, update.php will apply patch-editsummary-length.sql
even though it doesn't need to. But this partially wipes out the new schema from
tables.sql, and the omnibus comment and actor table patches don't detect
this, leading to filearchive missing the new fields.
Unlike the case with patch-add-3d.sql in I335cb8d9, here the patch does
make a change (if only a tiny one): fa_deleted_reason changes from TEXT
to BLOB.
Change-Id: I08047ff1207d471660365c0eb3faabc0b47746bb
On a fresh install, update.php will apply patch-add-3d.sql even though
it doesn't need to. But this partially wipes out the new schema from
tables.sql, and the omnibus comment and actor table patched don't detect
this, leading to image, oldimage, and filearchive missing the new
fields.
Since SQLite doesn't actually care about the values in the ENUM type
(it's just an alias for TEXT), let's just make patch-add-3d.sql do
nothing.
Change-Id: I335cb8d9626f535a66b0fe18e051640b22848ef7
MySQL, SQLite, PostgreSQL and MSSQL done with transitional patches.
One additional duplicate index removed from PostgreSQL schema.
Having a PK is essential to do maintenance, specially on large tasks.
By not having a PK it is impossible to add it in a safe way if not done
directly on the master.
Having a PK means that we can easily change the PK into another one if
needed in the future. The ones we chose might not be the best ones, but
will allow us to get them changed.
Bug: T198811
Change-Id: I6b96a427687085c6c24bcd759c9739f81288b919
To follow up I39b0825c, this change replaces the existing non-unique
index on the column with a unique index, to help avoid some of these
sort of bugs in the future.
Bug: T193180
Change-Id: I932478c9c6a13210bc9dff75286d0f08da56682c
Adds a maintenance script to populate the field, has that be
automatically run during update.php, and drops the no-longer-needed
default value on the column (where possible: mssql has some sort of
constraint thing going on that I have no idea how it works).
Bug: T59176
Change-Id: I971edf013a1a39466aca3b6e34c915cb24fd3aa7
This should have been done long ago. Now it is being done.
This also changes ar_text_id to NOT NULL, since it should never be null
anymore, and DEFAULT 0 in preparation for MCR stopping writing it.
Bug: T33223
Change-Id: I18f1c740b7537c7dc3cfeba9b241d0a9f31caa34
Revisions deleted before MediaWiki 1.5 do not have a value in this
field. This is going to be a problem for migration to the MCR schema, so
provide a maintenance script to clean this up.
Then, for good measure, change the schema to make the field
non-nullable.
Bug: T182678
Change-Id: Ie2e11f12a30f379db32c3e074658012c6f93adb0
The site stats table holds a bunch of metric fields, two of which are of
data type "bigint unsigned", 3 are "bigint" (signed) and one is int
(signed). Also the default values differ widely: It is 0 on the
"unsigned" fields and the "int" field, but -1 on the three others. This
patch makes all of this more consistent:
Set all fields (except the ss_row_id, which isn't changed) data type to
"bigint unsigned". Also set NULL as the default value for all those
fields. Obviously -1 isn't a possible default value any more. Also, 0
can easily be mistaken for a real value (e.g. ss_active_users=0 -->
"there is nobody active on this wiki"). NULL, by it's definition, is the
value of choice for a value to insert into fields of which we don't know
a correct value.
The respective patch files were tested locally against MySql, Sqlite,
Postgres and SQL Server 2016. Neither oracle nor the upgrade with
update.php was tested.
Bug: T56888
Change-Id: I7d42aae434852a56b6f8dd559d8a5f3bce416021
This adds a default of 0 for:
- Mssql
- Mysql
- Sqlite
The field is already NULLable in:
- Oracle
- Postgres
Bug: T188741
Change-Id: Ibe1cc363d21fb96f38c263181bf30a429a1c7b45
This begins the process of merging image_comment_temp into the image
table by adding the needed column. Iab5f5215 will adjust the code
to use it and to add the necessary migration script.
Note this patch puts the new schema change in the 1.30 section rather
than the 1.31 section. This allows Iab5f5215 to have migrateComments.php
migrate the comments directly to the new field instead of having to
populate and then depopulate the temporary table.
Bug: T188132
Change-Id: I2485c5a758bf03bb2b4991eea920abd9d0d30bda
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
Otherwise, the PK on log_search keeps getting dropped, ls_field_val readded and
this is then repeated on every run of update.php
Change-Id: I6b00933c29b5e24ec2833001fcf45053292d190c
Follows-up: Id635297838938c7c5dfe65d45285a4d16d65152d
WMF DBAs have been doing a massive effort to convert UNIQUE KEYS into
PRIMARY KEY.
Having a PK is essential to do maintenance, specially on large tasks.
By not having a PK it is impossible to add it in a safe way if not done
directly on the master.
Having a PK means that we can easily change the PK into another one if
needed in the future. The ones we chose might not be the best ones, but
will allow us to get them changed.
Bug: T172514
Change-Id: Id635297838938c7c5dfe65d45285a4d16d65152d
When revisions by logged out users are created, they will get copied
to this table. We can then JOIN it with revision when querying for
ranges at Special:Contributions.
DBA approval for this table can be found at T156318
Bug: T163562
Change-Id: I6593eb13701128faa782691a6b25ec01869c827d
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
This patch adds an ug_expiry column to the user_groups table, a timestamp
giving a date when the user group expires. A new UserGroupMembership class,
based on the Block class, manages entries in this table.
When the expiry date passes, the row in user_groups is ignored, and will
eventually be purged from the DB when UserGroupMembership::insert is next
called. Old, expired user group memberships are not kept; instead, the log
entries are available to find the history of these memberships, similar
to the way it has always worked for blocks and protections.
Anyone getting user group info through the User object will get correct
information. However, code that reads the user_groups table directly will
now need to skip over rows with ug_expiry < wfTimestampNow(). See
UsersPager for an example of how to do this.
NULL is used to represent infinite (no) expiry, rather than a string
'infinity' or similar (except in the API). This allows existing user group
assignments and log entries, which are all infinite in duration, to be
treated the same as new, infinite-length memberships, without special
casing everything.
The whole thing is behind the temporary feature flag
$wgDisableUserGroupExpiry, in accordance with the WMF schema change policy.
The opportunity has been taken to refactor some static user-group-related
functions out of User into UserGroupMembership, and also to add a primary
key (ug_user, ug_group) to the user_groups table.
There are a few breaking changes:
- UserRightsProxy-like objects are now required to have a
getGroupMemberships() function.
- $user->mGroups (on a User object) is no longer present.
- Some protected functions in UsersPager are altered or removed.
- The UsersPagerDoBatchLookups hook (unused in any Wikimedia Git-hosted
extension) has a change of parameter.
Bug: T12493
Depends-On: Ia9616e1e35184fed9058d2d39afbe1038f56d7fa
Depends-On: I86eb1d5619347ce54a5f33a591417742ebe5d6f8
Change-Id: I93c955dc7a970f78e32aa503c01c67da30971d1a
Use HTTPS instead of HTTP where the HTTP link is a redirect to the HTTPS link.
Also update some defect links.
Change-Id: Ic3a5eac910d098ed5c2a21e9f47c9b6ee06b2643
This is just the db part. The changes to UI validation code will
come in a dependent patch later.
This changes the max size of various *_comment, *_description
and *_reason fields to be 767 bytes. This size is chosen to
be consistent with the largest we can get away with while
still having covering indexes.
It also unifies the various data types of these fields to
varbinary. (Note, this was previously done and reverted in
r80547, but I don't think the reason for revert applies to
the edit summary fields)
MyISAM has a much smaller max index size, and this wouldn't
work with that storage engine. However, none of these fields
are used in default indexes (only in WMF indexes), so this
should not be an issue for anyone using MyISAM. Postgress
and sqlite already supported the larger edit summary size.
Note: This patch increases min mysql version to 5.0.3.
Bug: T6715
Change-Id: I8558e80a18e4591f07f2c3e80f792ea4435c4e71
Special page PageLanguage to set the page language of a page.
To enable the feature, set $wgPageLanguageUseDB to true
and assign the 'pagelang' user right to a user group.
Bug: 35489
Change-Id: I0f82b146fbe948f917c1c5d29f7469644d797e80
Field was removed in 1.23 from sql statements, but kept to allow easier
rollback on version update from 1.22 -> 1.23, when something gets wrong
with the new version.
Bug: 40667
Follow-Up: I4a9c2fa813d1f25dfb755e564f7677a212934d7b
Change-Id: I48989aceec31019f0b6c98aaeafaf60e975244df
Having the primary key at the top of the column definition looks nicer
and helps by finding him.
Oracle and Postgres already have this moved up.
Change-Id: Id8afbff35e165919f55dfcf1fd1dfaf1805d6aab
* New fields: ar_id, el_id. el_id is presently not used for
anything, but will help with online schema changes.
Bug: 15441
Bug: 39675
Change-Id: Ib6b0fc3736d173fa4ba7b786ecfc710b2f4711bb
The iwlinks and langlinks modules continue parameters imply ordering by
page then prefix then title. But in certain modes, the actual queries
use a different ordering, which may result in skipped or repeated
results.
This changeset fixes that. To do so, it needs to re-add an index
iwl_prefix_from_title which was mistakenly removed in 2010 (r69721). And
while it's doing that, it cleans up errors in the sqlite and postgresql
handling of the iwlinks indexes too.
Also, per Asher, make the iwl_prefix_from_title and
iwl_prefix_title_from indexes non-UNIQUE.
Change-Id: I607e8bf9183a2d8152a6127a81c83a0b5bba0c61
When enabling $wgProfileToDatabase, one would have to manually apply a
patch to the database that would add the `profiling` table. This patch
let update.php creates the table whenever $wgProfileToDatabase is true.
This also provide a SQL patch for SQLite backend and update
profileinfo.php to give some clue about enabling the global and running
update.php
Change-Id: If68a25f7ec2b0fbb61f82a318427abe58a89dae7
* Added support for different queue types and methods for storing queues.
* Treat each job type as being on its own queue, at least logically.
* Added $wgJobTypeConf to configure queue types for each job type.
* Improved the job DB table so that duplicate job checks actually work
and are faster. Also improved the method for popping rows of the table.
* Disabled duplicate job removal for everything except refreshLinks.
The DELETE statements just add DB overhead and are not useful for cheap
jobs, especially ones with start/end params (which are unlikely to have
exact duplicates).
Change-Id: I49824c7fa855fea4ddcac5c9901ece8c2c0101d0
This code is meant to replace the current interwiki code, but does not do so just yet. It is however used by the Wikibase extension. This allows us to try out some more things and have the code stabilize more before we migrate over existing interwiki functionality.
Change-Id: I23c47c2c3909a1500350fb560a5f2ec654e2c37e
