Page MenuHomePhabricator

Eventually, drop the conduit_connectionlog table
Closed, ResolvedPublic


This table is no longer used, but there's no particular reason to destroy it right away.

Event Timeline

epriestley claimed this task.
epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley changed the edit policy from "All Users" to "Community (Project)".
epriestley added a project: Conduit.
epriestley added a subscriber: epriestley.

I also put the DAO itself back to make storage adjust happy, so that should get nuked when the data is nuked.

epriestley lowered the priority of this task from Normal to Low.Dec 15 2015, 1:10 AM
eadler added a project: Restricted Project.Aug 5 2016, 5:24 PM

Let's permanently destroy some data! This will introduce you to how to perform schema changes.

We stopped writing to this table (which stored noisy but not-very-useful, mostly obsolete log information) about 8 months ago, but kept it around just in case there was some issue we missed. No one has complained, so we can be reasonably confident that it's safe to destroy forever.

Before making changes, you can verify that the table exists by doing this:

mysql> use phabricator_conduit;
mysql> show tables;

You should see a conduit_connectionlog table. It won't have any data since nothing has written to it for the better part of a year.

To destroy it forever:

  • Add a patch to resources/sql/autopatches/.
  • Name it YYYYMMDD.connectionlog.sql or similar, where YYYYMMDD is the current date (e.g., today is 20160822). By default, patches are executed in alphabetical order.
  • The patch should look like this:
DROP TABLE {$NAMESPACE}_conduit.conduit_connectionlog;
  • Delete the PhabricatorConduitConnectionLog.php file.
  • Run arc liberate src/ to rebuild the library map (this should remove references to the PhabricatorConduitConnectionLog class from the mapfile).
  • Run bin/storage upgrade to apply your patch. You should see it say that it applied the patch in the output. It should then exit successfully without complaining about any missing/excess indexes/tables/columns.
  • Use mysql to show tables again and make sure the table is really gone.