Opened 3 years ago

Last modified 2 years ago

#5447 new defect

Make disabling plugins less tricky

Reported by: Christopher Allan Webber Owned by:
Priority: major Milestone:
Component: programming Keywords: medium
Cc: Parent Tickets:


Now that we're using Alembic's branching model to enable long-running plugin migration branches, disabling plugins has gotten... complicated. From the current git master docs:

Deactivating plugins

You should be aware that once you enable a plugin, deactivating it
might be a bit tricky, for migrations reasons.  In the future we may
produce better tooling to accomodate this.  In short, you will need to
do a bit of database surgery by:

- Removing all tables and indexes installed by the plugin
- Removing the plugin's migration head id from the `alembic_version`
  table.  (You might be able to determine which to remove via
  examining the output of `./bin/gmg alembic heads`)

Note that this is a VERY TRICKY process, and you should be sure to make
a backup first.  You've been warned!

Well, obviously this isn't great. And the reason this isn't great is if you disable a plugin, the revisions for that plugin can't be found (because they aren't made available to alembic's migration path), and thus alembic is like "wtf is going on?"

So anyway, the docs suggest a method of "database surgery" to be able to install things, but of course manual surgery is unreliable. We should provide a parameter so that plugins can define their own "uninstall" rule that does this kind of manual surgery *for* the user (deleting tables, etc), and then delete the latest revision for that branch path.


Change History (1)

comment:1 Changed 2 years ago by Ben Sturmfels

Keywords: medium added

Marking as medium-sized. Will require a good understanding of Alembic migrations and the plugin API.

Note: See TracTickets for help on using tickets.