Page MenuHomePhabricator

Allow multiple slots to be used while still writing to the old as well as the new schema
Closed, ResolvedPublic

Description

We want to be able to write extra slots, such as the media-info slot for SDC, before we disable support for the old schema. Otherwise, enabling additional slots would be blocked on T183487: MCR schema migration stage 3: stop using legacy fields, which is probably going to take quite a while, since it means updating all legacy code that accesses the old database fields directly.

Implementing this should be as simple as removing a check that makes the RevisionStore reject revisions with extra slots.

Event Timeline

daniel created this task.Jun 28 2018, 5:59 PM
Restricted Application added a project: Wikidata. · View Herald TranscriptJun 28 2018, 5:59 PM
daniel renamed this task from Allow multiple slots to be used while still writing to the old schema to Allow multiple slots to be used while still writing to the old as well as the new schema.Jun 28 2018, 6:32 PM

Change 442903 had a related patch set uploaded (by Daniel Kinzler; owner: Daniel Kinzler):
[mediawiki/core@master] Allow extra slots in write-both/read-new mode.

https://gerrit.wikimedia.org/r/442903

daniel claimed this task.Jun 28 2018, 8:00 PM
Anomie added a comment.Jul 2 2018, 2:14 PM

Note a danger with this is that rolling back to "read-old" mode will remove access to the data in those slots.

  • If wikitext in the main slot or other pages can access the data in the non-main slots (e.g. via Scribunto or parser functions), that wikitext will break.
  • If pages are updated to depend on that data in some way, e.g. by removing license information from the main wikitext slot when entering it into the SDC slot, that data will no longer be displayed.
daniel added a comment.EditedJul 2 2018, 2:25 PM

@Anomie you are correct, but I don't see this as a huge problem, for two reasons:

  • rolling back to main-slot-only after people have started to use extra slots extensively is unlikely.
  • if it does happen, it would be temporary
  • the breakage would not be worse than what you get from deleting a template

But more importantly, the alternative is worse:
If we only enable the use of extra slots after we remove the support for the old schema, and we have to roll that back, *all* content of new revisions would become inaccessible!

The only way to avoid this is to allow the use of new slots while we still write the old schema. That way, if we have to roll back, we can at least still access the content of the main slot. That may be incomplete, but better than nothing.

But I'll add a note to the description of T198308 that reflects your concern.

Anomie added a comment.Jul 2 2018, 3:44 PM

For the record:

On IRC #mediawiki-core, @daniel and @Anomie wrote:

<DanielK_WMDE> anomie: replied to you in https://phabricator.wikimedia.org/T198413#4384839
<DanielK_WMDE> am i missing something? i don't think we can avoid the "if we roll back, we lose access" situation. we can only try to mitigate the fallout.
<anomie> DanielK_WMDE: I think the important thing is to be aware that such a rollback will break things, both for us and for people on-wiki who might start using this while a rollback is still a possibility.
<anomie> e.g. so no one runs a bot removing license data from wikitext in favor of SDC until we're sure the rollback won't happen.
<DanielK_WMDE> anomie: oh, I agree! It just sounded to me like you were advising against the change, though.
<DanielK_WMDE> i see no way to make the migration step less risky.
<anomie> Sorry for the confusion.
<DanielK_WMDE> but the risk shoud be noted clearly on the ticket. i have added a not accordingly

Change 442903 merged by jenkins-bot:
[mediawiki/core@master] Allow extra slots in write-both/read-new mode.

https://gerrit.wikimedia.org/r/442903

daniel closed this task as Resolved.Jul 8 2018, 4:29 PM