Re: Testing 1.7a2 -- pre_migrate and post_migrate (py2.7)

[Val Neekman]

Is the following statement still valid?

"Any handlers that listen to this signal need to be written in a particular place: a management module in one of your INSTALLED_APPS. If handlers are registered anywhere else they may not be loaded by migrate."

1. I scanned the source and did not find the code imposing the above statement.

2. Handlers that are not in the management directory are still called.

Unless the statement means something different or the supporting code has been removed.

Thanks,

Val

[Carl Meyer]

On 02/11/2014 12:11 PM, Val Neekman wrote:
> Is the following statement still valid?
>

> "Any handlers that listen to this signal need to be *written* in a

> particular place: a management module in one of your INSTALLED_APPS

> <https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-INSTALLED_APPS>.
> If handlers are *registered* anywhere else they may not be loaded
> by migrate
> <https://docs.djangoproject.com/en/dev/ref/django-admin/#django-admin-migrate>."

>
> 1. I scanned the source and did not find the code imposing the above
> statement.
> 2. Handlers that are not in the management directory are still called.
>
> Unless the statement means something different or the supporting code
> has been removed.

I would assume that this is not an explicitly-imposed restriction, it's
just a natural consequence of the fact that modules in your codebase
that are imported by a normal request-handling server process may never
be imported when you run manage.py migrate, whereas you can be assured
that that the "management" module will be imported (because that's where
Django searches for management commands in the first place).

I would also guess (although this should be verified) that this warning
could be updated to include models.py modules as a safe place to
register these handlers; it may be that this documentation was written
before the app-loading updates, but post-app-loading it should be
guaranteed that by the time a management command runs all models of all
installed apps are imported.

Carl

[Carl Meyer]

Actually, let me correct myself - this documentation probably should be
updated to recommend registering these signal handlers (and all other
signal handlers) in the ready() method of an AppConfig, rather than as
an import side effect anywhere.

Carl

[Aymeric Augustin]

On 11 févr. 2014, at 20:20, Carl Meyer <ca...@oddbird.net> wrote:

> this documentation probably should be
> updated to recommend registering these signal handlers (and all other
> signal handlers) in the ready() method of an AppConfig, rather than as
> an import side effect anywhere.

Indeed, that’s the best practice as of Django 1.7.

--
Aymeric.

[Val Neekman]

Yeah, I do remember times where I had to put the signal handlers in the urls.py in order to lazyfy them, hence, avoiding the circle-dance. Of course, they would not fire via the management commands.

Ok, good to have the AppConfig.ready() for that.

Thanks,

Alight, Perhaps, I should create a ticket and enhancement for the documentation update.

Thanks,

Val

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8B2A0448-6CDA-457D-BF76-E7EBDD786A4D%40polytechnique.org.

For more options, visit https://groups.google.com/groups/opt_out.