Change Details

Fields that will become unused with MCR schema migration should be hidden in the toolforge replica of the wikidatabases, to avoid tools from reading incomplete/inconsistent data. These fields will eventually be dropped anyway, and will stop to be updated when T198312 is done, which is expected to happen by the end of the year [[https://docs.google.com/spreadsheets/d/1TkznqoaMH6HTQBSMxXPRhSOo8auf1oMLx6c-Cjjf-Sk/edit?ts=5b43c255#gid=0|MCR migration plan]]. Affected fields are: page.page_content_model revision.rev_content_model revision.rev_content_format revision.rev_text_id These fields should become unavailable on toolforge soon, following an appropriate notice period. NOTE: this ticket originally asked for compatibility to be maintained by adding joins to the views for the page and revision table. This idea has been dropped due to performance issues, see T195515. ---- == Migrating Tools to the New Schema == Tools that need to know the content model of a revision's content can look it up using the new `slots` and `content` tables, which are already available on labs. The following query returns the content model of a revision's main slot: SELECT content_model, model_name FROM slots JOIN content ON slot_content_id = content_id JOIN content_models ON model_id = content_model WHERE slot_revision_id = 12345 AND slot_role_id = 1. The `slot_role_id = 1` in the end indicates the revision's `main` slot. See https://www.mediawiki.org/wiki/Multi-Content_Revisions/Database_Schema for reference. The last join provides the model name for the model ID. It may be more sensible to do this programmatically: This mapping never changes and only very rarely grows, so it can be cached aggressively, or even be hard coded for the well known models (e.g. 1 for wikitext). NOTE: rev_content_format and rev_text_id are only relevant when loading serialized blobs from external storage, which is not possible on toolforge. They are removed without replacement.

Fields that will become unused with MCR schema migration should be hidden in the toolforge replica of the wiki databases, to avoid tools from reading incomplete/inconsistent data. These fields will eventually be dropped anyway, and will stop to be updated when T198312 is done, which is expected to happen by the end of the year [[https://docs.google.com/spreadsheets/d/1TkznqoaMH6HTQBSMxXPRhSOo8auf1oMLx6c-Cjjf-Sk/edit?ts=5b43c255#gid=0|MCR migration plan]]. Affected fields are: page.page_content_model revision.rev_content_model revision.rev_content_format revision.rev_text_id These fields should become unavailable on toolforge soon, following an appropriate notice period. NOTE: this ticket originally asked for compatibility to be maintained by adding joins to the views for the page and revision table. This idea has been dropped due to performance issues, see T195515. ---- == Migrating Tools to the New Schema == Tools that need to know the content model of a revision's content can look it up using the new `slots` and `content` tables, which are already available on labs. The following query returns the content model of a revision's main slot: SELECT content_model, model_name FROM slots JOIN content ON slot_content_id = content_id JOIN content_models ON model_id = content_model WHERE slot_revision_id = 12345 AND slot_role_id = 1. The `slot_role_id = 1` in the end indicates the revision's `main` slot. See https://www.mediawiki.org/wiki/Multi-Content_Revisions/Database_Schema for reference. The last join provides the model name for the model ID. It may be more sensible to do this programmatically: This mapping never changes and only very rarely grows, so it can be cached aggressively, or even be hard coded for the well known models (e.g. 1 for wikitext). NOTE: rev_content_format and rev_text_id are only relevant when loading serialized blobs from external storage, which is not possible on toolforge. They are removed without replacement.

Fields that will become unused with MCR schema migration should be hidden in the toolforge replica of the wiki databases, to avoid tools from reading incomplete/inconsistent data. These fields will eventually be dropped anyway, and will stop to be updated when T198312 is done, which is expected to happen by the end of the year [[https://docs.google.com/spreadsheets/d/1TkznqoaMH6HTQBSMxXPRhSOo8auf1oMLx6c-Cjjf-Sk/edit?ts=5b43c255#gid=0|MCR migration plan]]. Affected fields are: page.page_content_model revision.rev_content_model revision.rev_content_format revision.rev_text_id These fields should become unavailable on toolforge soon, following an appropriate notice period. NOTE: this ticket originally asked for compatibility to be maintained by adding joins to the views for the page and revision table. This idea has been dropped due to performance issues, see T195515. ---- == Migrating Tools to the New Schema == Tools that need to know the content model of a revision's content can look it up using the new `slots` and `content` tables, which are already available on labs. The following query returns the content model of a revision's main slot: SELECT content_model, model_name FROM slots JOIN content ON slot_content_id = content_id JOIN content_models ON model_id = content_model WHERE slot_revision_id = 12345 AND slot_role_id = 1. The `slot_role_id = 1` in the end indicates the revision's `main` slot. See https://www.mediawiki.org/wiki/Multi-Content_Revisions/Database_Schema for reference. The last join provides the model name for the model ID. It may be more sensible to do this programmatically: This mapping never changes and only very rarely grows, so it can be cached aggressively, or even be hard coded for the well known models (e.g. 1 for wikitext). NOTE: rev_content_format and rev_text_id are only relevant when loading serialized blobs from external storage, which is not possible on toolforge. They are removed without replacement.