关于python：Django pre_save 信号不起作用

Django pre_save signal does not work

我通过以下方式测试了Django的”pre_save”信号，但都无法捕捉到信号。

1
2
3
4
5
6

from django.db.models.signals import pre_save
import logging

def my_callback(sender, **kwargs):
logging.debug(“======================================”)
pre_save.connect(my_callback)

在 manage.py shell 中运行上述代码：
然后我运行我的网站，看到 models.save() 工作成功，但回调函数没有运行。

或者，我再次在 shell 上运行上述代码，然后在 shell 中运行 models.save()。”保存”再次运行良好，但回调函数仍然没有任何反应。

最后，我将上面的代码嵌入到一个 __init__.py 文件中，然后在网站上运行 save() 函数。不过，什么也没发生。

你能帮我弄清楚为什么 pre_save 信号似乎不起作用吗？

相关讨论

您是否尝试在 models.py 文件中添加代码？

您没有将发送者类设置为一个。

1
2
3
4
5
6
7

from django.db.models.signals import pre_save
from myapp.models import MyModel
import logging

def my_callback(sender, **kwargs):
logging.debug(“======================================”)
pre_save.connect(my_callback, sender=MyModel)

其次，如果你使用的是 Django 1.3，你应该使用新的装饰器语法。

1
2
3
4
5
6
7
8
9
10
11
12

# Inside your models.py
from django.db import models
from django.db.models.signals import pre_save
from django.dispatch import receiver

class MyModel(models.Model):
field1 = models.TextField()
field2 = models.IntegerField()

@receiver(pre_save, sender=MyModel)
def mymodel_save_handler(sender, **kwargs):
logging.debug(“======================================”)

应该可以，但我还没有测试过代码，所以如果它仍然损坏，请告诉我。

相关讨论

您不需要指定发送者类，也不需要使用装饰器语法。它不起作用的原因不是上述任何一种，这是因为他将信号附加到不同线程中的保存发生的位置。
请注意，要使@receiver 代码正常工作，您还需要从 django.dispatch 导入接收器
由于某种原因，此代码仅在信号接收器位于信号发射器所在的同一 model.py 中时才有效(模型)。

logging.debug() 正在使用根记录器，其处理程序级别默认为 30 (\\’WARNING\\’)。

=> logging.debug(‘something’) 根本没有做任何事情(调试级别为 10 < 30)。请参阅 http://docs.python.org/2/library/logging.html

应该使用另一个自定义记录器进行相同的测试，或者通过执行以下操作：

1
2
3
4
5

l = logging.getLogger()
l.setLevel(10)
def my_callback(sender, **kwargs):
logging.debug(“======================================”)
pre_save.connect(my_callback)

最初的问题没有包含足够的信息来了解它是否是 OP 面临的真正问题(或部分问题)。
但可以肯定的是，OP 的代码不适用于我的 ./manage.py shell

Eric 的回答使它起作用的原因是因为他让您在 models.py 中连接信号，因此当您通过您的网站保存模型时，信号处理程序与信号触发程序处于同一进程中.

在示例 1 和 3 中，很容易看出它们为什么不起作用 – 您将保存在与信号接收器正在收听的不同进程(网站)中。

我希望我能更好地理解为什么示例 2 也被破坏了，但我只是在我自己的项目中调试了一个类似的问题，同时在 shell 中测试信号，这肯定与信号发送器和接收器无法\\ ‘见\\’ 对方。

相关讨论

我不知道这是否是正确的解释，但这绝对是有趣的，值得被批评或投票。但我不明白为什么它会是一个不同的线程或进程……
这是一个不同的过程，因为一个是 manage.py shell 会话，另一个是 manage.py runserver …它是相同的代码库，但它们是独立运行的，因此对 shell 中的对象所做的更改(信号处理程序的连接)可以’ t 影响 Web 服务器中的等效对象
(很确定”过程”是正确的术语，而不是我在评论埃里克的回答时使用的”线程”)
是的，我认为它适合 1，但如果它是 django app init.py 则不适合 3(两者都不是)。另外，这个 logging.debug 对我来说似乎很可疑 => 看我的回答
同意 3，只要代码在 Web 服务器中重新加载

如 django 信号文档中所述，pre_save 信号接受 3 个唯一参数(不是关键字参数)，因此，您需要将 my_callback 函数编辑为如下：