Postgres:
- Set empty string as default for wl_title to match MySQL
- Drop foreign key from wl_user
- Change wl_namespace datatype from SMALLINT to INT to match MySQL/SQLite
- Drop PG-specific indexes and sync them with MySQL
Bug: T230428
Bug: T164898
Change-Id: Ie996b81ca59069443976b90d7bcdce29997d768a
Additional changes for Postgres:
- Set empty string as default for qci_type
- Set PG-equivalent of the given MySql/Sqlite timestamp as
default timestamp for qci_timestamp
- Make qci_type non nullable
- Make qci_timestamp non nullable
- Drop UNIQUE constraint on qci_type
Bug: T230428
Bug: T164898
Depends-On: If344395615087c360597a5b3d66ea03e930b7d9b
Change-Id: I741d2d079696d4b4eba09945341054d2a145bddc
For Postgres:
- Dropping foreign key on ug_user
- Setting default on ug_user and ug_group
- Renaming indexes so they would be the same as MySQL/Sqlite
Bug: T42626
Bug: T164898
Bug: T230428
Change-Id: If507d8b8f363016760fe34aac2a0e0a2d99b66aa
Sqlite doesn't need any change as binary/varbinary both turn into BLOB.
For Postgres:
- Dropping foreign key on pr_page, as all FKs should be dropped (See
T164898)
- Add all of indexes, it seems PG was missing all four indexes of the
MySQL version and didn't have any
- Changing PK from (pr_page,pr_type) to (pr_id).
- Had to add changePrimaryKey function to handle such cases, similar
to checkIndex
- Set pr_page to not nullable
Bug: T42626
Bug: T164898
Bug: T230428
Change-Id: Ied11f9c2ee633bf5ae325a6c2ea163dcc8d8d3c5
Yes, name of that table is really querycachetwo.
For migrating MySQL/Sqlite, changed data type of qcc_title and
qcc_titletwo to varbinary.
For migrating Postgres, just renaming indexes to stay in sync with
MySQL/Sqlite was enough.
Bug: T230428
Change-Id: I43952836ce184419622a6f851cb5e9319172d656
Turning qc_title to varbinary in MySQL to make it consistent with the
rest of fields.
For Postgres:
- Setting 0 as default for qc_value and qc_namespace
- Changing data type of qc_namespace from SMALLINT to INT to make it
the same with MySQL/Sqlite
- Renaming index to make it the same with other schemas
- Setting empty string as default of qc_title
Bug: T230428
Bug: T164898
Change-Id: I81527121609014d29182ae735a2c1f532d7d4d2a
Also dropping the fkey on ir_ipb_id in Postgres as approved by RFC T164898
Bug: T230428
Bug: T164898
Change-Id: Iaddec3b9992eee39fe82a45d5bda59bd51cde510
Also fixing one schema data type drift between MySQL and Postgres
and fixing the problem with booleans, currently DBAL turns "boolean" to
TINYINT(1) in MySQL because it doesn't support it but it leave it like
that in Postgres which in turn breaks it because mediawiki currently
doesn't cast values properly, so for now just turning them to SMALLINT
which is the status quo (See T257755#6335566)
Bug: T230428
Bug: T164898
Change-Id: Ia495a451d51722496942b720a32393f7a6728dee
This takes advantage of custom data type registered in the previous
commit.
Also fixing Postgres drift by dropping the sequence, PK of this table is
not autoincrement so it shouldn't have sequence in Postgres.
Bug: T230428
Bug: T164898
Change-Id: I4c10990ead1e52c979254d2ac6a25ccf62a31508
In order to migrate MySQL and Sqlite to abstract schema changed the
cat_title data type from varchar binary to varbinary. This wouldn't
affect production.
For migrating Postgres, renamed two indexes from category_* to cat_* to
make it in sync with MySQL/Sqlite
Bug: T164898
Bug: T230428
Change-Id: Iad11aa4f7d809465cb20ac9748bf52b0e1bcd5a4
In order to migrate MySQL and Sqlite to abstract schema changed the
iwl_title data type from varchar binary to varbinary. This wouldn't
affect production.
For migrating Postgres:
- Turning the unique index to PK to make it in sync with MySQL
Bug: T164898
Bug: T230428
Change-Id: Iaa625b66c874023b8cf2403917fa2fa120279208
In order to migrate MySQL and Sqlite to abstract schema changed the
ll_title data type from varchar binary to varbinary. This wouldn't
affect production.
For migrating Postgres:
- Dropping foreign key on ll_from
- Setting default of empty string for ll_lang and ll_title
- Make ll_lang and ll_title both non-nullable to be in sync with MySQL
- Turning the unique index to primary key, similar to MySQL
- Renaming an index to sync with MySQL
Bug: T164898
Bug: T230428
Change-Id: I57f22896ff67266f99bf08f6dd1b9cc4c51b1db9
In order to migrate MySQL and Sqlite to abstract schema changed the
il_to data type from varchar binary to varbinary. This wouldn't
affect production.
For migrating Postgres:
- Dropping foreign key on il_from
- Setting default of empty string for il_to
- Completely rewriting indexes to make it synced with MySQL
Bug: T164898
Bug: T230428
Change-Id: I59f0d0a56d938a168bf1c7de2a1be47f15d1add1
In order to migrate MySQL and Sqlite to abstract schema changed the
tl_title data type from varchar binary to varbinary. This wouldn't
affect production.
For migrating Postgres:
- Dropping foreign key on tl_from
- Changing data type of tl_namespace from SMALLINT to INT and setting
its default
- Setting default of empty string for tl_title
- Completely rewriting indexes to make it synced with MySQL
Bug: T164898
Bug: T230428
Change-Id: Idbb65d870f58f7146b9c8bd860e6530bef1e0f12
In order to migrate MySQL and Sqlite to abstract schema changed the
pl_title data type from varchar binary to varbinary. This wouldn't
affect production.
For migrating Postgres:
- Dropping foreign key on pl_from
- Changing data type of pl_namespace from SMALLINT to INT and setting
its default
- Setting default of empty string for pl_title
- Completely rewriting indexes to make it synced with MySQL
Bug: T164898
Bug: T230428
Change-Id: I4af8202742a1826e6b3f8ff36cf4f7b612b82690
Changing "varchar() binary" to varbinary in MySQL and Sqlite for two
columns: rd_title and rd_fragment.
Fixing db drifts of schema in Postgres:
- Setting the data type of rd_namespace from SMALLINT and setting its
default
- Set empty string as default of rd_title
- Changing datatype of rd_interwiki to varchar (PG supports that)
Bug: T164898
Bug: T230428
Change-Id: I9563792b1fc0ce5f3de78c08703a768a0c2e99d0
Also, fixing two data type drifts in Postgres:
- lc_key was varchar (with no binary flag) in MySQL but TEXT in
Postgres while PG supports varchar. Changing PG to varchar.
- lc_value was BYTEA but the rest of varbinary fields are mapped to
TEXT, changing it to TEXT data type.
And fixing primary key of these tables in Postgres too as it was a unique index instead.
Bug: T198811
Bug: T164898
Bug: T230428
Change-Id: I50305556bd870461d05f98c5272cf1d6a65deb15
content.content_id was BIGINT in MySQL (and Sqlite) but INT in Postgres
so making Postgres BIGINT as well.
Bug: T230428
Bug: T164898
Change-Id: Ib8492e224478dc069ba17e489f7b2bb22d5da804
Also ls_value was varchar (with no binary flag) in MySQL but TEXT in
Postgres while PG supports varchar. Changing PG to varchar.
Bug: T230428
Bug: T164898
Change-Id: I2f7fae7b1e781021cb7d3ed39c40c2fc9d20a680
Also, dropping foreign key constraint on user_properties.up_user as it's decided to
drop all of foreign key constraints in T164898
And fixing primary key of the table in Postgres as it was a unique index
instead.
Bug: T198811
Bug: T164898
Bug: T230428
Change-Id: I60a2b65df62ec93a363309f8a17c29b83fd6f058
Six fields were BIGINT in MySQL (and Sqlite) but INT in Postgres
so making Postgres BIGINT as well:
- ss_total_edits
- ss_good_articles
- ss_total_pages
- ss_users
- ss_active_users
- ss_images
Bug: T230428
Bug: T164898
Change-Id: I527b2797af3c8ba1a7402a4428b565f8e35cc132
Three fields were BIGINT in MySQL (and Sqlite) but INT in Postgres
so making Postgres BIGINT as well:
- slot_revision_id
- slot_content_id
- slot_origin
Bug: T230428
Bug: T164898
Change-Id: I5333cc0cbdc36356bd865ae118b883bc367c31eb
comment.comment_id was BIGINT in MySQL (and Sqlite) but INT in Postgres
so making Postgres BIGINT as well.
Bug: T230428
Bug: T164898
Change-Id: I29a1878eea2adfd6e7d8ad85a94dc83718f9671e
bot_passwords.bp_token didn't have a default in Postgres while it has
one in MySQL (and Sqlite), so adding the default to Postgres as well
Bug: T230428
Bug: T164898
Change-Id: I0ae4dbf8f2a5382081c6211c9cad51843000e3f1
Also during the abstraction, fixing the schema drift between MySQL
and Postgres in these two tables by removing foreign key, sequences,
and changing data types (as outlined in T164898)
Bug: T230428
Bug: T164898
Change-Id: If737a746629511b5a53d7ae70328fd558bd58d0e
And fixing the schema drift between mysql and postgres in this table by
changing field type of ul_key and ul_value from TEXT and TEXT to
VARCHAR(255) and BYTEA respectively.
The automatic generation is done with running generateSchemaSql.php
maintenance script. More info:
https://www.mediawiki.org/wiki/Manual:Schema_changes#Automatically_generated
Bug: T230428
Bug: T164898
Change-Id: Id785539d32546166d6f7a5c3cb1924f4841a2963
This adds the rev_id column to the end of the rev_actor_timestamp index
to make it unambiguous. With the id field added, the index matches the
pagination criterion for user contributions (filter by actor, sort by
timestamp, then disambiguate based on revision id). The index is not
marked UNIQUE since this would potentially degrade write performance.
Uniqueness is already guaranteed by the rev_id field being the primary
key.
Note that no provisions are made to change the definition of the
rev_actor_timestamp index for existing instances. This index was only
recently added in I18071a2fe45907a0cf1b0fefebd96a97a2dacb7b and has not
been part of any release. It has also not yet been created on the wikimedia
servers. For this reason, any existing instances are assumed to be for
testing only. Instances would also continue to function normally with
the previous index definition.
With this patch, the new index will be created correctly when updating
from 1.34 or earlier. It will however not be modified for installations
of some development version of 1.35.
Bug: T200259
Bug: T238966
Change-Id: I511bb21b1ca820d950818cc831f8e3fef43a1559
We're finally to the point of making the massive alter to the `revision`
table that we've been building up to for 2.5 years now.
Changes here are:
* Drop `rev_text_id`, `rev_content_model`, and `rev_content_format` that
MCR obsoleted.
* Drop `ar_text_id`, `ar_content_model`, and `ar_content_format` that
MCR obsoleted.
* Replace `rev_comment` with `rev_comment_id`.
* Replace `rev_user` and `rev_user_text` with `rev_actor`, plus
associated index changes.
Future patches will make the code changes to migrate data from
`revision_actor_temp` and `revision_comment_temp` into the new
`revision` columns.
Bug: T251343
Bug: T184615
Bug: T215466
Change-Id: I18071a2fe45907a0cf1b0fefebd96a97a2dacb7b
In mysql the user_id and user_ip fields are not nullable,
but include a default 0 and '', however in Postgress the default
was not set, while user_id was set to not nullable. In the
code that uses this table, we set either user_id or user_ip
depending on whether the user is anon or registered. Thus both
fields should either be nullable, or contain a default.
Given that mysql has defaults set, I've opted for bringing
Postgress closer to what mysql does.
This was always broken and was discovered by adding new tests
for this functionality.
Bug: T239640
Change-Id: I75bf469a30225687a4b0cb550a4068cb07208c01
This table will store expiries for watchlist items, so that pages can be
automatically unwatched at a specific time.
Bug: T240094
Change-Id: I014ffccb91969e7a222a83858c55e71067b0f2af
This removes most of the pre-actor user and user_text columns, and the
$wgActorTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_user and rev_user_text remain 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_comment, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
ActorMigration'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. Code using
ActorMigration for accessing the core fields should be updated to use
the new actor fields directly. That will be done for in a followup.
Bug: T188327
Change-Id: Id35544b879af1cd708f3efd303fce8d9a1b9eb02
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
Update the database schema so a block can be switched between a sitewide and
partial block. Also add the restrictions table for specifiying the partial
blocks.
Bug: T197144
Change-Id: I4a725312c4b980a1b14e5ca826069fa2278a5913
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
