Page MenuHomePhabricator

Decide whether back-compat views for upcoming major schema changes will be provided in the Labs replicas
Closed, ResolvedPublic

Description

There are several major schema changes in the planning and early development stages:

  • T166732 will replace columns such as rev_comment, ibp_reason, img_description, and so on with id fields referencing a separate comment table.
  • A similar change will replace columns such as rev_user/rev_user_text, ipb_by/ipb_by_text, and so on with id fields referencing a new 'actor' table.
  • Content model and format fields will be changing to ids too.
  • And, of course, MCR will drop a number of revision fields (rev_text_id, rev_len, rev_sha1, rev_content_model, rev_content_format), moving them to a 'content' table with multiple content rows corresponding to one revision.
  • There's also a proposal, currently unresourced, to change various namespace+title fields (e.g. pl_namespace and pl_title) into id fields referencing a central namespace+title table.

I don't know if there are any statistics as to how many tools would be broken by these changes, or if there's even any way to really determine that.

It has been suggested that these changes might be eased in Labs by providing "old" versions of the views for the affected tables. For example, while the revision view would presumably change to match the schema changes, an old_revision view that pulls in the revision, user, and main slot data in a manner similar to the current schema might be provided (temporarily). This would allow existing tools to simply switch table names to keep working while their code is being updated to the new schemas.

Event Timeline

bd808 added a comment.Jun 5 2017, 8:33 PM

I don't know if there are any statistics as to how many tools would be broken by these changes, or if there's even any way to really determine that.

The only thing the cloud-services-team could think of would be grepping logs from the Quarry tool to see how often these tables are queried from there. That is at best a small approximation of the number of queries that would happen from Labs generally.

It has been suggested that these changes might be eased in Labs by providing "old" versions of the views for the affected tables.

Since this would still require code changes I'm not sure that it much of a win for the typical volunteer project.

-jem- added a subscriber: -jem-.Jun 8 2017, 10:57 AM
Blahma added a subscriber: Blahma.Jun 8 2017, 12:41 PM
Bstorm closed this task as Invalid.Feb 8 2019, 6:14 PM
Bstorm added a subscriber: Bstorm.

This is already done, much less decided. We have decided that providing back-compat was very bad in terms of performance (after doing it and finding out), so there are now _compat named views for those who want to keep the functionality (changing tables rather than changing schema for reading the tables) as an "opt-in" functionality for volunteers that might be easier in some cases. It looks like this task got lost in the dust clouds.

Anomie changed the task status from Invalid to Resolved.Feb 8 2019, 6:58 PM

I hope you don't mind, I'm going to change this from "invalid" to "resolved".

To me, "invalid" means the task is based on a faulty premise or is incoherent or spam. That doesn't describe this task.

I think "resolved" fits best, because the task asked for a decision and we eventually decided, even though we didn't document the decision here or make the decision with knowledge of this task specifically.

I chalk it up mainly to coincidence that, after a false start with a different solution, we wound up doing what was proposed here. Except named like revision_compat rather than old_revision. (:

Bstorm added a comment.Feb 8 2019, 6:59 PM

Fair enough :)