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
Put a single blank line between a CREATE TABLE and each accompanying
CREATE INDEX, but two blank lines between those statements and the next
CREATE TABLE.
Change-Id: I8ae8a3c808a772a338e968213031d390bf1b31ca
Previously, a first str_replace() would add a single newline before any
CREATE (TABLE or INDEX), and then a second one would add another newline
after the $wgDBTableOptions, resulting in a blank line between any two
CREATEs and also a newline at the end of the file – at least for MySQL
schemas. But PostgreSQL and SQLite schemas don’t use $wgDBTableOptions,
so the second str_replace() was a no-op for them, and they got no blank
line between CREATEs nor a newline at the end of the file. Fix this by
making the first str_replace() insert two newlines and appending a final
newline all the time.
Bug: T260779
Change-Id: Idcc4fae76d382b559f21234f8a6f49e537a60f11
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
