Enabling hooking into the autodetector from a third-party app.

[Emil 'Skeen' Madsen]

Idea and motivation presented on the ​mailinglist

Summed up, what I suggest is:

• Creating a new signal fired from within the autodetector to allow third-party apps to generate migrationfiles with their own custom operations within them.

One compelling use-case for this, is automatically generating database constraints based upon querysets (see the mailinglist post for details).

[Simon Charette]

Hello Emil, thanks for posting to the mailing list before submitting a new feature request.

I can't say this feature wouldn't be useful for other purposes but your Meta.constraint_triggers motivation could likely be implemented with the ​new constraints API by subclassing Constraint to return custom SQL for trigger/function creation and removal.

I think it should be preferable that you try using this interface and report any missing feature first than allowing third party apps to hook into the non-formalized and already complex auto-detector logic. I'll close the ticket for the aforementioned reasons but feel free to gather more feedback on your ML thread to demonstrate wide interest in this feature.

[Emil 'Skeen' Madsen]

Hello Simon,

I have been able to implement my library via the new constraints API. Thank you for the hint.
The library now lives at:

• ​https://pypi.org/project/django-queryset-constraint/
• ​https://github.com/magenta-aps/django_queryset_constraint

---

I could conceivably similarly utilize the new constraints API to achieve the side goals I listed, such as:

• Automatically enabling database extensions, when fields which require these extensions are utilized
• Add comments to database tables

However I believe this would be overloading the constraints API for something it was never designed for.
So, do you have any ideas, as to how I would achieve these side goals without hooking into the autodetector and without utilizing the constraint API?
If not, that is perfectly okay, these are, as stated, merely side goals.

[Simon Charette]

I have been able to implement my library via the new constraints API. Thank you

You're welcome, thanks for giving it a try. It looks like this will likely be useful for a few people.

If I can give you a suggestion regarding the implementation I'd avoid the self.queryset == other.queryset in __eq__ as this will likely result in two queries during comparison which is quite frequent during auto-detection and operation reducing. Instead I'd compare each of the string representation of queries which is a documented API. That is str(self.queryset.query) == str(other.queryset.query). I submitted ​a PR for it.

I could conceivably similarly utilize the new constraints API to achieve the side goals I listed, such as:

• Automatically enabling database extensions, when fields which require these extensions are utilized
• Add comments to database tables

There's ​an ongoing effort to add pre and post_operation signals (#29843) for this purpose but in the team you can rely on pre_migrate to inject CreateExtension into the plan if a CreateModel, AddField, or AlterField has a field requiring an extension. Ditto with table comments.

[Emil 'Skeen' Madsen]

Hi,

Thanks for the feedback, the library is still in a very early stage, and I really dislike how the M object is implemented.
If you happen to have a good idea for serializing a queryset, that would be lovely.

Thanks for the links!