Makemigrations hooks for third-party apps?

[Craig de Stigter]

Hi there

I'm in the early stages of developing a third party app which makes heavy use of postgres extensions. The app provides an abstract model, so I won't have direct control of user's models or migrations. I'm having trouble getting it to generate sensible migrations for users.

At present the migration process for users is going to be "copy and paste my migration file template into your project, and change the model names to match your app". As far as I can tell there is no way to generate migrations with anything custom.

The operations I need to generate are:

• CreateExtension()
• RunSQL() - (to create slightly non-standard constraints)

e.g. perhaps my model could supply a couple of methods:

• Model.Meta.pre_creation_operations() - returns a list of operations to apply before the auto-detected model operations, e.g. creating extensions etc
• Model.Meta.post_creation_operations() - the same but applied after the auto-detected operations, e.g. adding constraints/indexes.

I'm envisaging that the operations returned from both methods would be deconstructed and copied into migration files when makemigrations is run.

Has there been any discussion about this previously? I haven't found any.

Thanks

Craig de Stigter

[charettes]

Hello Craig,

There's unfortunately no way to hook into the migration auto-detector to specify
additional operations to be added.

What I suggest you do instead is dynamically inject operations in the plan that
is about to be run by connecting a pre_migrate signal. When you detect
CreateModel operations for subclasses of your AbtractModel you could insert
operations to be performed before and after them. This is pattern we use
internally to perform ContentType rename on RenameModel operations[0].

As for the makemigrations hooks I think it would require a lot of thought and
efforts to get right. Right now the auto-detector is a black box that deals with
dependencies and model state deltas resolution.

In an ideal world model/fields objects would be able to generate the list of
operations they require to move from state A to B as a public API and the
auto-detector would simply iterate over the existing migrations state models and
compare them against the current state of the project.

Best,
Simon

[0] https://github.com/django/django/blob/525dc283a68c0d47f5eb2192cc4a20111d561ae0/django/contrib/contenttypes/management/__init__.py#L45-L84

[Josh Smeaton]

Can you provide the operations that users can then import into their migrations, similarly to how contrib.postgres provides the HStoreExtension operation [0]? The import could even be a function taking the extended model that returns the appropriate operation. This might be a bit more lo-fi than hooking the pre-migrate signal, and require users to do the right thing, but it sounds better than copy/pasting templates.

[0] https://docs.djangoproject.com/en/1.11/ref/contrib/postgres/operations/#creating-extension-using-migrations

[Javier Buzzi]

A bit late, unrelated: what is the reason behind not having django just add the extension `HStoreExtension` when it detects `hstorefield`? From what i can see, there there is a `create .. if not exists` on the sql command, and seems like a no brainer.

Thanks