Multi-Content Revisions/checklist

Is MCR right for my use case?

This is a checklist for determining whether MCR is a good choice for storing some kind of “data” that is to be associated with a wiki page in some way. Note that the storage layer of MCR is fully functional, but integration with various aspects of the UI have to be manually.

• Is the data user-editable?
  • yes: MCR or main content (on a subpage or embedded), if the data also needs to be versioned.
  • no: Could use MCR with a “derived slot”, but only makes sense if the data is derived from the main content, needs to be available for past revisions as well, and is very expensive to re-compute. It may be better to rely on ParserCache or some other caching mechanism.
• Is the data associated with a specific wiki page?
  • yes: MCR or main content (on a subpage, associated namespace, or embedded)
  • no: store/cache elsewhere, should not use revision storage with MCR or as main content.
• Do you need the data to be versioned?
  • yes: MCR or main content (on a subpage or embedded, though embedding in wikitext is discouraged)
  • no: store/cache elsewhere, should not use revision storage with MCR or as main content.
• Do you need old versions of the data to be tied to specific versions of the main content?
  • yes: Use MCR or embed data (though embedding in wikitext is discouraged). Cannot be done (well) with a subpage or associated namespace.
  • no: Could use MCR, but could also use a subpage (or associated namespace)
• Do you want changes to the data and the main content to me made together in a single edit, to ensure consistency and allow them to be previewed together?
  • yes: Use MCR, there is really no other way to achieve this
• Does the data need to be protected along with the main content?
  • yes: Use MCR or embed data (though embedding in wikitext is discouraged)
• Does the data need to be (un)protected independently of the main content?
  • yes: Currently not supposed by MCR. Use a subpage (or associated namespace), or implement per-slot restriction management.
• Does the data need to be moved along with the main content?
  • yes: Use MCR or embed data (though embedding in wikitext is discouraged)
• Does the data need to be deleted (and un-deleted) along with the main content
  • yes: Use MCR or embed data (though embedding in wikitext is discouraged)
• Do we need to be able to delete the data without deleting the main content?
  • yes: MCR supports this (similar to the way embedding the data does), but UI is lacking.
• Should the data be included in XML dumps (for backup, archival, import/export)?
  • yes: MCR supports this out of the box. Embedding and using separate pages support this as well.
  • no: Filtering of slots for import/export would need to be added to MCR (shouldn’t be too hard).
• Should users who are watching the main content also be notified about changes to the data?
  • yes: MCR supports this out of the box, without MCR it’s probably messy.
  • no: Not currently supported by MCR. Could be suppressed on edit or filtered out on retrieval (would require a schema change). Or use a subpage (or associated namespace).
• Should changes to the data be visible in the RecentChanges and Watchlists timeline?
  • yes: MCR supports this out of the box. Using a separate (sub)page or embedding the data in wikitext would also achieve this.
  • no: Not currently supported by MCR. Could be suppressed on edit or filtered out on retrieval (would require a schema change).
• Should changes to the data be visible in the user contributions list?
  • yes: MCR supports this out of the box. Using a separate (sub)page or embedding the data in wikitext would also achieve this.
  • no: Not currently supported by MCR. Could be suppressed on edit or filtered out on retrieval (would require a schema change). However, if changing the data isn’t considered a “contribution”, MCR is probably not a good fit.
• Do we need content suppression to work for the data?
  • yes: MCR supports this, but currently not per-slot, but only for all content of a page.  Implementing per-slot suppression would require a schema change.
  • no: suppression would still be applied when using MCR. MCR applied the same slow-level access checks for all content.
• Should a special permission be required to edit the data?
  • yes/no: MCR allows text-based slots to be edited via the editpage API, and applies the same permission checks that would apply for the main content. For other kinds of content, a specialized UI or API needs to be created, which would have control over which permission checks are to be used.
• Should the data be used in the search index to find the page it is associated with?
  • yes: MCR supports this out of the box. Embedding the data in the main content would also work, but embedding in wikitext is discouraged. Subpages and associated namespaces do not support this.
• Do we need to run queries against the current revision of the data?
  • yes: ContentHandler supports extraction of secondary data, both to standard data structures such as links tables and page-data, as well as additional custom structures. This is supported for the main content of a page as well as additional slots (MCR)
• Do we want the archival storage of the data to be in a specialized database that is aware of its structure? Do we want to avoid serialized data storage?
  • yes: MediaWiki currently does not support this, but the mechanism for this was considered in the design of MCR and can easily be put into place (see T209044).
  • no: can rely on generic blob storage provided by MCR.

Notes:

• editing has to go via mediawiki (or rather, you push to the “archive” via MW). The frontend can be elsewhere. And the frontend can write to another store as well.