[Wikidata-bugs] [Maniphest] [Commented On] T198492: Create a maintenance script to drop rev_text_id and ar_text_id from the database.

[tstarling]

tstarling added a comment.


  In T198492#5471572 , 
@Anomie wrote:
  
  > Maybe that was true 15 years ago, but update.php seems well-established now.
  
  No, it was never true. update.php has been used to drop fields since MW 1.5, 
14 years ago, but there was no backlog of undropped fields at that time. 
update.php has always been the correct script in which to drop fields and 
tables.
  
  Obviously we should take care to avoid losing data. But that's the case 
whether the update code is in update.php or another script.

TASK DETAIL
  https://phabricator.wikimedia.org/T198492

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: tstarling
Cc: tstarling, Aklapper, Anomie, Jdforrester-WMF, Tgr, daniel, darthmon_wmde, 
DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, 
JJMC89, B20180, _jensen, rosalieper, Agabi10, Wikidata-bugs, aude, Mbch331, 
Ltrlg
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T198492: Create a maintenance script to drop rev_text_id and ar_text_id from the database.

[Anomie]

Anomie added a comment.


  In T198492#5471360 , 
@daniel wrote:
  
  > I think what we have done in the past was simply nothing. We would just 
have left these fields in, forever. Or told people to run an SQL patch by hand.
  
  {{citation needed}}
  
  Maybe that was true 15 years ago, but update.php seems well-established now.
  
  > I don't see the problem with letting other scripts do schema changes if 
they assert the preconditions.
  
  Schema changes on Wikimedia sites are done by the DBAs, for one. Having 
maintenance scripts other than update.php making such changes means more 
cognitive load.
  
  Also update.php is currently our one entry point for making schema changes. 
Having them spread across multiple scripts means that someone wanting to keep 
their wiki's schemas up to date has a harder time of it.
  
  If we ever get around to the plans I have for Abstract Schemas, that includes 
having tests for "start with MW 1.X's schema, run updates, now it needs to 
match the current schema". Which would be broken by some schema changes not 
being part of the set of updates.
  
  > The question is how risky a bug in that code would be. Automatically 
converting and then immediately burning all bridges seems rather risky.
  
  It's basically the same thing you proposed, except relying on humans to do 
the checking of things.

TASK DETAIL
  https://phabricator.wikimedia.org/T198492

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Anomie
Cc: Aklapper, Anomie, Jdforrester-WMF, Tgr, daniel, darthmon_wmde, DannyS712, 
Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, _jensen, 
rosalieper, Agabi10, Wikidata-bugs, aude, Mbch331, Ltrlg
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T198492: Create a maintenance script to drop rev_text_id and ar_text_id from the database.

[daniel]

daniel added a comment.


  In T198492#5471347 , 
@Anomie wrote:
  
  > update.php is the standard mechanism for schema changes, and I don't think 
we ever have any other maintenance scripts perform actual schema changes. I 
don't think setting a precedent for doing schema changes in arbitrary 
maintenance scripts is at all a good idea.
  
  I think what we have done in the past was simply nothing. We would just have 
left these fields in, forever. Or told people to run an SQL patch by hand.
  
  I don't see the problem with letting other scripts do schema changes if they 
assert the preconditions.
  
  > A solution I've used in the past is a custom method in DatabaseUpdater that 
checks the relevant global and ensures that the relevant migration maintenance 
script runs to completion successfully (with the equivalent of --force) before 
applying the change.
  
  The question is how risky a bug in that code would be. Automatically 
converting and then immediately burning all bridges seems rather risky.
  
  > Our maintenance scripts never require additional input, as this prevents 
(or at least complicates) automation. Again, this seems like a precedent we 
shouldn't set.
  
  That's exactly the idea here: this change should not be automated. It should 
be deliberate and manual. We could have --force skip the confirmation, sure.

TASK DETAIL
  https://phabricator.wikimedia.org/T198492

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Aklapper, Anomie, Jdforrester-WMF, Tgr, daniel, darthmon_wmde, DannyS712, 
Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, _jensen, 
rosalieper, Agabi10, Wikidata-bugs, aude, Mbch331, Ltrlg
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T198492: Create a maintenance script to drop rev_text_id and ar_text_id from the database.

[Anomie]

Anomie added a comment.


  In T198492#5470617 , 
@daniel wrote:
  
  > @daniel renamed this task from //**Drop rev_text_id and ar_text_id when 
running update.php**// to //**Create a maintenance script to drop rev_text_id 
and ar_text_id from the database.**//.
  
  
  
  In T198492#5470617 , 
@daniel also wrote:
  
  > Having update.php remove them seems risky, so we'd just leave them until 
someone manually runs a script. The script should be written to avoid 
accidental data loss. In particular, it MUST not run (and output a meaningful 
error message) if $wgMultiContentRevisionSchemaMigrationStage is defined and 
has the SCHEMA_COMPAT_READ_OLD or SCHEMA_COMPAT_WRITE_OLD flags set (even after 
this config variable officially no longer exists).
  
  update.php is the standard mechanism for schema changes, and I don't think we 
ever have any other maintenance scripts perform actual schema changes. I don't 
think setting a precedent for doing schema changes in arbitrary maintenance 
scripts is at all a good idea.
  
  A solution I've used in the past is a custom method in DatabaseUpdater that 
checks the relevant global and ensures that the relevant migration maintenance 
script runs to completion successfully (with the equivalent of --force) before 
applying the change.
  
  > It must also present the user with a warning that running this script 
before the schema migration is complete results in irrecoverable data loss, and 
prompt for confirmation.
  
  Our maintenance scripts never require additional input, as this prevents (or 
at least complicates) automation. Again, this seems like a precedent we 
shouldn't set.

TASK DETAIL
  https://phabricator.wikimedia.org/T198492

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Anomie
Cc: Aklapper, Anomie, Jdforrester-WMF, Tgr, daniel, darthmon_wmde, DannyS712, 
Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, _jensen, 
rosalieper, Agabi10, Wikidata-bugs, aude, Mbch331, Ltrlg
___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs