- The ALTER TABLES to run: https://gerrit.wikimedia.org/r/#/c/255662/3/sql/patch-store-revision-ids.sql
- Where to run those changes: extension1, DB: wikishared
- When to run those changes: With train on next Tuesday (14 December)
- If the schema change is backwards compatible: compatible with the current code deployed.
- If the schema change has been tested already on some of the test/beta wikis. Usually, as a last test, change should be applied to testwiki first: We will be testing on Labs, Beta and testwiki (along with deployment).
- If it involves new columns or tables, if the data should be made available on the labs replicas. Similar question if it involves deletion of data previously available on labs.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T76456 Language Engineering tracker of trackers (tracking) | |||
| Open | None | T127695 Design polishing for Content Translation | |||
| Resolved | • santhosh | T95886 for ContentTranslation MT, store information about source content, machine-translated content and user-edited content | |||
| Resolved | • santhosh | T111905 Design the technical infrastructure for parallel corpora storage and api (tracking) | |||
| Open | None | T102107 Enable Content Translation in Catalan Wikipedia for all logged-in users | |||
| Open | None | T102966 Allow to continue published translations (when they have no additional modifications) | |||
| Resolved | • santhosh | T119495 Save the revision id of source and published article in cx_translations table | |||
| Resolved | jcrespo | T119752 Review schema changes for T119495 |
Event Timeline
Comment Actions
Dropping #blocked-by-schema-change because as far as I know I am not the one blocking this "(We will schedule this)". Please readd it when it is actually being blocked by a DBA (adding the regular DBA tag).
Comment Actions
@jcrespo, we can proceed this now as code will be deployed with next train run and table need to updated before it.
Comment Actions
Thanks, however, I cannot guarantee it will be done by 14. It is the end of my day, and tomorrow traditionally only emergency deployments are done.
I will try to perform it on Monday, but as documented on the tag, usually I ask for 2 weeks of advance notice. In this case it *may* be doable, but only because it is on the x1 server and there is not a lot of traffic on these tables (assuming no other more urgent ask arrives between now and Monday). Apologies for this.
Comment Actions
The change has been applied successfuly, and no regression has been noted. This is the new table structure:
Create Table: CREATE TABLE `cx_translations` (
`translation_id` int(11) NOT NULL AUTO_INCREMENT,
`translation_source_title` varbinary(512) NOT NULL,
`translation_target_title` varbinary(512) NOT NULL,
`translation_source_language` varbinary(36) NOT NULL,
`translation_target_language` varbinary(36) NOT NULL,
`translation_source_url` blob NOT NULL,
`translation_target_url` blob,
`translation_status` enum('draft','published','deleted') DEFAULT NULL,
`translation_start_timestamp` varbinary(14) NOT NULL,
`translation_last_updated_timestamp` varbinary(14) NOT NULL,
`translation_progress` tinyblob NOT NULL,
`translation_started_by` int(11) DEFAULT NULL,
`translation_last_update_by` int(11) DEFAULT NULL,
`translation_source_revision_id` int(10) unsigned NOT NULL,
`translation_target_revision_id` int(10) unsigned NOT NULL,
PRIMARY KEY (`translation_id`),
UNIQUE KEY `cx_translation_pair` (`translation_source_title`,`translation_source_language`,`translation_target_language`),
KEY `cx_translation_languages` (`translation_source_language`,`translation_target_language`)
) ENGINE=InnoDB AUTO_INCREMENT=94833 DEFAULT CHARSET=binary
1 row in set (0.00 sec)This was easier than I feared due to the low usage at the time of the schema change.
Comment Actions
@jcrespo A small mistake happened, the patch sql that Kartik linked was pointing to an older patchset. Later Niklas made those two columns nullable(translation_source_revision_id and translation_target_revision_id ). See Niklas comment above.
See the diff https://gerrit.wikimedia.org/r/#/c/255662/3..10/sql/patch-store-revision-ids.sql
Fortunately the int type fields get default value 0 and nothing breaks now.
But to make it future-proof, we would like to get those fields nullable as per the last PS at https://gerrit.wikimedia.org/r/#/c/255662/
Sorry for the confusion.
Comment Actions
Schema changes cannot be reverted. See: https://wikitech.wikimedia.org/wiki/Schema_changes
Please create a new task for a new schema change based on the current state.
Comment Actions
Schema changes cannot be reverted. See: https://wikitech.wikimedia.org/wiki/Schema_changes
There is no revert involved.
Please create a new task for a new schema change based on the current state.
Done. See T121509: Correct the schema to make revision id columns of cx_translations nullable