Topic on Talk:Multi-Content Revisions/Database Schema

No changes to the page, revision, or archive tables are needed for MCR. Some fields in these tables become meaningless, however - in particular the fields containing content model and format. These can be dropped later.

Most of these seem unrelated to MCR, and unneeded for MCR.

• A bigint for rev_id would probably make sense, although that seems mostly a separate concern from MCR. I'd say leave that change for a separate project. The only dependency is the type of slot_revision, but there are many other fields in the DB that have a similar dependency.
  • If we want to do this at the same time as any MCR-related schema changes, it shouldn't be too hard to do it.
• Again, your questions for rev_page seem unrelated to MCR. Let's leave that for a separate project, MCR is big enough as it is.
• ar_text and ar_flags still exist because old rows deleted in MediaWiki before 1.5 were never migrated to the text table. We should really do that someday so we can get rid of this column.
• Regarding ar_rev_id not referring to an existing revision, it is the "existing" revision. A migration to merge it with ar_id would need to invent IDs for existing pre-1.5 rows without conflicting with any existing rev_id or ar_rev_id.
• Your question on page_namespace is entirely unrelated to MCR.
• page_restrictions may need old rows migrated before being dropped (a count using the enwiki replica on tool labs reports 4102 rows that have a value here). Again, this seems unrelated to MCR.

Yes, none of this is needed for MCR. In fact, the MCR was intentionally designed so it would function with no change to the page, revision, or archive table. My intention was to provide an overview of other planned or possible changes that will effect these tables, and also to say which fields become redundant through MCR.

I suppose I should make it clear for each change if it's a) needed for MCR b) made possible by MCR c) has no causal relationship and is mentioned purely for information.