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, but not yet populated. Populating these tables is part of {T183488}. Once this is done, reading from the new schema will be enabled on the main cluster (see T198308).
At that point,. theThe following query returns the content models of a revision's main slots::
SELECT slot_role_idcontent_model, content_modelmodel_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.
Note that this will return multiple rows ifThe `slot_role_id = 1` in the end indicates the revision has multiple's `main` slots. See https://www.mediawiki.org/wiki/Multi-Content_Revisions/Database_Schema for reference.
The meaning of slot_role_id can be looked up inlast join provides the model name for the `slot_roles`table,model ID. the meaning of content_model can be looked up in `content_models`.It may be more sensible to do this programmatically: This mapping never changes and only very rarely grows, This couldso it can be done with a joincached aggressively, but it mayor even be more sensible to do this programmatically. This mapping never changes and only very rarely grows,hard coded for the well known models (e.g. so it can be cached aggressively1 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.