| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the standard in every extension. DB schema changes are not
maintenance scripts, and therefore there's no apparent reason to have
the two things together, besides historical reasons.
Also, put each DB type in a separate directory, which wasn't the case
for MySQL before. For SQLite and Postgres schema changes, we now
follow the convention (used everywhere else, including the
generateSchemaChangeSql script) of having the DB type as the last part
of the path. This lets us generate schema changes for all DB types at
once, and without specifying the full file path.
Most files are just being renamed, the exceptions being to update
references to the old location (sometimes still referencing tables.sql).
Note that the old path is still referenced in the autogenerated comment
of schema changes SQL files. These will be regenerated in another
commit. Instead, the schema files are done now, because they're covered
by DatabaseIntegrationTest that would otherwise fail.
Bug: T382030
Change-Id: I3b4a614366d0bc629523ac40ce97d001f3b6bcf8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Make si_page primary key
- Allow si_title to be larger
- Switch from utf8 to utf8mb4
- Remove default of empty string for titles
Sqlite is not migrated, as it has it's own overrides
Postgres is migrated, but is not in actual use
This is mostly from I273e3a7715abf97d2889904642c7c375e76de4f6
Bug: T249976
Bug: T231827
Change-Id: I12adff3e6ca6a9986ff207bef16272195c3a6a48
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improve maintainability of update-keys.sql by moving the list from an
SQL file to a PHP array in the same file as the updates it is disabling.
It was apparently an SQL file for the convenience of third parties
wishing to install MediaWiki by manually sourcing tables.sql. Support
this use case by adding an option to update.php which inserts the update
keys. Users should source tables-generated.sql and then run
update.php --initial
The array is the same for each DB type, but it's correct for it to have
the same scope as getCoreUpdateList(). Factoring out common parts of
getCoreUpdateList() and this new array is a separate project.
Bug: T167924
Change-Id: I404ee29aadcc2f3f24f78d1111090395129cd021
|
|
|
|
|
|
|
| |
It has been dropped in production already.
Bug: T299947
Change-Id: I8ec1e7d9224c81d6494c39c78df9e4bdac38d377
|
|
|
|
|
|
|
|
|
|
|
|
| |
Migrate from ipblocks to block/block_target and drop the ipblocks
table. Update tests.
In PostgresUpdater, change some schema update functions to skip field
updates if the table doesn't exist, by analogy with
DatabaseUpdater::modifyField.
Bug: T346293
Change-Id: Icf91b35f7f729cead7c800429653eb30731762a1
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
Per official policy, updates from versions older than two LTS releases
are not supported.
Change-Id: I8fb08e226c1a37580f95ee622a0703eee312d9ba
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Wikidata is at 51.3% of its maximum value (see [1]), so we still have
comfortable time to make this change, but it will inevitably be
necessary and there is no point in postponing this change into the
future. The autoincrement value will not get smaller. ¯\_(ツ)_/¯
Also since rc only stores stuff for 30 days, the table is not that
big.
[1] - https://grafana.wikimedia.org/d/79S1Hq9Mz/wikidata-reliability-metrics?viewPanel=29&orgId=1
Bug: T63111
Change-Id: Icf3dc9815814ef73aa6a39f1c221a349e6b76872
|
|/
|
|
|
|
|
|
|
| |
* Drop default value from rev_actor and rev_comment_id
* Make rev_id a bigint
Bug: T215466
Depends-On: I88318d7bcc063bc86a56eeb5f00048ea6e81964b
Change-Id: Id0a3d920e8b2dc8643fa3c0341b34ab3ed5761dc
|
|
|
|
|
|
|
|
|
|
|
|
| |
After exhuastive research, we concluded that iwl_prefix_from_title is
not used and in case it's actually used, other indexes provide enough
cardinality.
This table is about to grow quite large in Commons, let's avoid making
it bigger than it needs to be.
Bug: T343131
Change-Id: I89e40dff384291968d2465e4109a3d212ae2f8c7
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This table has eight indexes plus PK. It has around 1000 rows only. Even
if it needs these indexes (which it doesn't), they are still useless.
Looking at the code, the only potential useful index is the one on
site_global_key, they are showing up in the report of unused indexes in
the db and I checked with Fandom (which might benefit from an index on
this table) and they said they don't use sites table.
Bug: T342856
Change-Id: I06b3db0f33bd35bfa68f4b418d8c2f4b9b988409
|
|
|
|
|
|
|
| |
Unused since Ie4dd91ee29308c980e
Bug: T342854
Change-Id: I3acf563c64ff176ade3e0c6745839a168e92473b
|
|
|
|
|
| |
Bug: T346293
Change-Id: I3822ad03227405a608dea1d788bcdb8321b95bb3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why:
* Part of a temporary user name is generated from an index that
increments, which is stored in the database.
* As specified in T345855, the index will be restarted each year.
* Also specified in T345855, the year will be included in
generated temporary user names.
What:
* Since the year must be included in the name in order to avoid
naming conflicts if the index is restarted each year, both are
implemented together and controlled by a single config.
* Add a new config option that, when true, restarts the name
generation index at the start of each year and add the year into
the user name: $wgAutoCreateTempUser['serialProvider']['useYear']
* Add a uas_year column to the user_autocreate_serial table, which
is unique in combination with uas_shard, so the index can be
stored for each shard/year combination.
* The year is added into the username just after the prefix, as
specified in T345855. This is based on research that having the
year near the start of the name aids understanding that the
names are not IP addresses. The position of the year within the
name is therefore not configurable (though whether to include
it is). See T345855 for the research.
Bug: T349494
Bug: T349501
Depends-On: I6b3c640a4e74f52fd4a4f46de5a2cbe80fe3b665
Change-Id: If51acb3f4efa361ce36d919c862a52501a5a7d24
|
|
|
|
|
| |
Bug: T351619
Change-Id: I52304efae870fcbe14dbacbff20ff69d6481c71c
|
|
|
|
|
|
|
|
| |
This is meant in preparation for MediaWiki supporting files
larger than 4gb.
Bug: T191805
Change-Id: Ie67dd01aa0a8b28d9afc1805243e711fcadbc0f8
|
|
|
|
|
|
|
|
|
|
| |
Already dropped from production
Also dropping FixExtLinksProtocolRelative as it's not useful anymore and
it has been run in previous releases so it's not worth fixing.
Bug: T312666
Change-Id: I1dd6e704b34e685ada6e316da11243d10827d769
|
|
|
|
|
|
|
| |
Similar to templatelinks
Bug: T342689
Change-Id: I2ed692d7d0cdf756d29618363bec7fc761ff3df1
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to drop these columns and we need to make them take default
values so we can issue write queries without these columns.
Also noting that MySQL prior to 8.0 can't set default values to blob
columns making this way more complicated than it should be but MariaDB
can set them (https://mariadb.com/kb/en/blob/). We also made these
columns nullable to make this work in MySQL.
Bug: T341828
Change-Id: I0d60742b6ce7adf642393ee00b66aa539b76dfc1
|
|
|
|
|
| |
Bug: T299954
Change-Id: I85d21b1eff70a7d70e8ce14f25d66f7e7c76e5fe
|
|
|
|
|
|
|
|
|
| |
This allows temporary users to be identified from applications
external to MediaWiki, by the user table alone (without referring
to the $AutoCreateTempUser['matchPattern'] config).
Bug: T333223
Change-Id: I83c5ff42654164590fb0361c84e65a5315ddbda8
|
|
|
|
|
|
|
|
|
| |
Given that we now have abstract schema, any schema produced for SQLite
will be produced specificly for SQLite, no need to do regex gymnastics
that are hard to understand, maintain and obviously prone to break.
Bug: T326181
Change-Id: I58741ff82460cfd9a350440d50b293ba67e3c939
|
|
|
|
|
|
|
| |
Per official policy, updates from versions older than two TLS releases
are not supported.
Change-Id: I3dc98fe61c8a508aa3ade694f8c0a6a00115031b
|
|
|
|
|
| |
Bug: T318604
Change-Id: I217817bc518eaa86c9952187c6f1a861f480ccaf
|
|
|
|
|
|
|
|
|
|
| |
These files are not needed anymore. Either because they are orphan now
and no updater will run these sql files.
Or they are maint scripts to migrate the data and that has been removed
in I5ff9630a65 and I84bd1d3dbe7
Change-Id: I00c49d8d649e3fa7641f3c57bf3ea4440ae542df
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per official policy, updates from versions older than two TLS releases
are not supported.
Finding the implicit marker is a bit tricky. The user might try to
upgrade from a really old version that doesn't have tag_summary table
and mistakenly think it's new and allow upgrade. So turning the check
logic into a boolean AND where it must be new enough to have
change_tag_def table AND new enough not to have tag_summary table.
Change-Id: I5ff9630a6539a587a47930847e108ac53757106f
|
|
|
|
|
|
|
|
|
|
| |
Per official policy, updates from versions older than two TLS releases
are not supported.
We can drop more versions, given that 1.39 is LTS but to ease the
review, let's drop one release per patch
Change-Id: I84bd1d3dbe777909e30710fff5bcb655af9a4261
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
- schema change to allow tl_namespace and tl_title being empty
This is done by removing them from primary key. They don't need to be
nullable as they have default value.
- Make sure with WRITE_NEW, updater avoids writing to the old columns
Bug: T306674
Change-Id: I2b8a29043e952060e7a79b6a7a3d647d48cd16fb
|
|
|
|
|
| |
Bug: T35334
Change-Id: I17e73d5ef165481a5dd4c210da933b99c65ff79c
|
|
|
|
|
|
|
| |
It is being dropped in production
Bug: T215466
Change-Id: I66b2cb8653252e720c897351065978119f040ba7
|
|
|
|
|
|
|
|
|
|
| |
I have updated user_editcount field to unsigned in
tables.json
This patch doesn't apply to Postgres.
Bug: T305340
Change-Id: I07a360944a10be9cc8ed8731c6286412294413a3
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It makes it more consistent with AUTO_INCREMENT PRIMARY KEY columns on
other tables.
This includes ipblocks.ipb_parent_block_id and
ipblocks_restrictions.ir_ipb_id as well
This patch doesn't apply to Postgres.
Bug: T297208
Change-Id: I950aba63b2b226abbaf4010fbb51415bbff117f4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add services and utilities for automatic creation of temporary user
accounts on page save, in order to avoid exposing the user's IP
address.
* Add $wgAutoCreateTempUser, for configuring the system
* Add TempUserConfig service, which interprets the config.
* Add TempUserCreator service, which creates users during page save as
requested by EditPage. With proxy methods to TempUserConfig for
convenience.
* Add table user_autocreate_serial. Table creation is necessary before
the feature is enabled but is not necessary before deployment of this
commit.
Bug: T300263
Change-Id: Ib14a352490fc42039106523118e8d021844e3dfb
|
|
|
|
|
|
|
| |
The policy allows this and since 1.39 is going to be the next LTS
release, I think it is fine to do this now.
Change-Id: If426e0ee349252ccc0ba9c4222c7d6865ab57fa2
|
|
|
|
|
|
|
|
| |
Part of normalizing it, note that the field must be nullable now and
that will change later.
Bug: T299418
Change-Id: Id543dfa20a153312f66d2f45a64ac23e7272dabe
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This includes:
page_props.pp_page
page_restrictions.pr_page
ipblocks_restrictions.ir_value
These columns must hold all possible values from page.page_id,
which is an unsigned integer.
These patches doesn't apply to Postgres.
Bug: T297212
Change-Id: I789f19f4d52daeab08f3090771404d078f86d0b3
|
|
|
|
|
|
|
| |
This is already applied in production and known to be safe.
Bug: T163532
Change-Id: Ief29372f13b2d7cdb19395dcda6eb15e9a53efca
|
|
|
|
|
| |
Bug: T299416
Change-Id: Icae4513dd99635335857100d8a0c7102986933e5
|
|
|
|
|
|
|
| |
It's not used for 13 years, safe to say it won't be used anytime soon
Bug: T199377
Change-Id: Iecf4fb6046699a1758ad2d1dc55a3ee8eb4b0389
|
|
|
|
|
|
| |
The table calls sites
Change-Id: I361e1a3207259ef4d85f1e46b3c75f4d655ff0b6
|
|
|
|
|
|
|
|
| |
Since the branch cut has happened, we can bump and get rid of legacy
cruft. According to the policy we can go up to 1.31 but let's keep it
that way to avoid major distruptions.
Change-Id: I9d697445a3bb5047726c8b2a7f808edb8403cdda
|
|
|
|
|
| |
Bug: T270033
Change-Id: I8a429726c99f6cadea0d671fd871f66b5611c856
|
|
|
|
|
| |
Bug: T270033
Change-Id: Id70d0e0a37dd0d000079820d51cef2791f5ec42e
|
|
|
|
|
|
|
| |
Mirroring what happens on image table.
Bug: T279982
Change-Id: Ib67c32b10d3b88e09514d8fbb5dcb4f977108ba2
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
Mistake during the abstraction (Ibdaf332ea1d)
It doesn't need schema change since 1.36 is not released yet.
Bug: T230428
Change-Id: I071c39dfadf185b01e9109085907d6e3deb1f02f
|
|
|
|
|
|
|
|
| |
Rename to `rev_page_timestamp`
Bug: T270033
Depends-On: I16fc273b14e7f4b00e8c31ec1ed7712149aafe37
Change-Id: I93fcfb3caf8c6bd7f9e46921065b751c23571ae1
|