Add Operation.allow_migrate().

[George Sakkis]

Most Django migration operations call self.allow_migrate_model() in database_forwards/database_backwards to check if the operation should be applied. There are two exceptions however: RunPython and RunSQL. These don't go through self.allow_migrate_model() but call directly router.allow_migrate(), passing arbitrary self.hints as keyword args (conversely, all other operations don't support arbitrary hints; the only fixed hints are model_name and model). This difference is problematic for any library/function that tries to inspect or modify the behavior of arbitrary migration operations.

I'd like to propose a new Operation.allow_migrate() method which will act as the single point of access to the router: all migration operations will call it (directly or indirectly) in database_forwards/database_backwards. By default this is just a wrapper around router.allow_migrate() but it can (and will) be overriden.

Happy to work on a PR if the idea is accepted.

[Mariusz Felisiak]

Thanks for this ticket. I think it's reasonable to add Operation.allow_migrate() that would be called by special operations RunSQL() and RunPython(), e.g.

def allow_migrate(self, db, app_label, **hints):
    return router.allow_migrate(db, app_label, **hints)

however I don't think it's a desired change to call it in the model-specific operations that rely on allow_migrate_model() because currently

Operation.allow_migrate_model() --- calls ---> Router.allow_migrate_model() --- calls ---> Router.allow_migrate()

I don't see where in this flow we could call the new Operation.allow_migrate() without breaking the current behavior.