Rename pre/post_migrate argument db to using

[Anssi Kääriäinen]

All the other model signals have argument 'using', but pre/post_migrate have the same information (that is, connection's alias) in argument db.

[Denis Cornehl]

wanted to work on this.

I assume we have to follow the deprecation policy since we change the name of the provided kwarg?

[Simon Charette]

@syphar, the deprecation policy doesn't apply here since those signals we're never part of a public release; they are only present on the master branch.

[Denis Cornehl]

Just a thought, then why did Andrew keep not used arguments and built the new signals as alias to the old ones?

• see this (​https://github.com/django/django/commit/68e0a169c4f9fa7f8071e014b274fd59e970f9a3),
• deprecation here ​https://github.com/django/django/blame/master/docs/internals/deprecation.txt#L167

It seems like the two kwargs create_models and created_models are only kept to stay backwards compatible.
Or am I wrong and these arguments _are_ still important, even if you use migrations? (so, not comparable to this ticket).

Thanks for looking into this.

[loic84]

@charettes pre/post_syncdb which now alias to pre/post_migrate were public though.

Instead of aliasing I would keep pre/post_syncdb as their own thing and just let the db arg die along with them, that would also allow a DeprecationWarning which is currently missing.

I think it's a win-win, we do the cleanup and we offer a better deprecation path than currently.

PR coming soon.

[Denis Cornehl]

@loic84
i have a WIP branch here

• ​https://github.com/syphar/django/compare/master...ticket_21477

feel free to use it.

Won't be able to finish it today.

No DeprecationWarning atm, but I like the idea.

[loic84]

@syphar I somehow missed your earlier comment, I guess we were writing at the same time, ccing to the ticket so I get a heads up next time.

There is indeed an issue with create_models and created_models. They are used internally for things like ​https://github.com/django/django/blob/master/django/contrib/sites/management.py#L15, I'm not sure what will be the replacement. Anyhow that's probably outside the scope of this ticket.

I also have a very similar branch with the deprecation warnings: ​https://github.com/loic/django/compare/syncdb_signals.

You claimed the ticket first, so I'll defer to you; feel free to ping me if you'd rather me to take it from there.

[Denis Cornehl]

I've tried to put the work by loic84 and me together. Result is this here:
​https://github.com/django/django/pull/1983
I also added tests for the DeprecationWarning

I'm not entirely sure if

• the documentation should be done differently (no experience here on my side)
• the DeprecatedSignal is a thing we will need more often and if we should make it more general and put into ​https://github.com/django/django/blob/master/django/utils/deprecation.py

Any thoughts on this?

[Andrew Godwin]

I like this approach - we get a DeprecationWarning for the old signals out of it too, which is a bonus.

I vote +1 on moving DeprecatedSignal somewhere more general (deprecation is probably good, or possibly django.dispatch). Docs look good apart from one small typo that I noted on the PR.

Fix those and make the PR mergeable and I'll pull it in.

[loic84]

The DeprecationWarning is hardcoded, so if we move DeprecatedSignal with the goal of making it generic it should probably take the warning level as an __init__ argument.

[loic84]

These patches also address the deprecation of the pre/post_syncdb signals which IMO should be part of Django 1.7.

Bumping the severity to Release Blocker as a result, please revert if you think otherwise.

[Aymeric Augustin]

I've restored pre/post_syncdb and made pre/post_migrate a different set of signals since this discussion.

[Aymeric Augustin <aymeric.augustin@…>]

In d562527a160f420c6af0d2736ad4e6c87b0d2ef1:

Fixed #21477 -- Renamed db to using in pre/post_migrate signals.