If you want to compare state before and after save action, you can use pre_save signal which provide you instance as it should become after database update and in pre_save you can read current state of instance in database and perform some actions based on difference. from django.db.models.signals import pre_save from django.dispatch import receiver @receiver(pre_save, … Read more
you can use update instead of save in the signal handler queryset.filter(pk=instance.pk).update(….)
I think I figured out a way to do this. There is a ‘raw’ parameter in the kwargs passed in along with signals so I can replace my test above with this one: if (kwargs.get(‘created’, True) and not kwargs.get(‘raw’, False)): Raw is used when loaddata is running. This seems to do the trick. It is … Read more
You’re not going to. M2Ms are saved after instances are saved and thus there won’t be any record at all of the m2m updates. Further issues (even if you solve that) are that you’re still in a transaction and querying the DB won’t get you m2m with proper states anyways. The solution is to hook … Read more
If you’re using Django<=1.6 I’d recommend Kamagatos solution: just import your signals at the end of your models module. For future versions of Django (>=1.7), the recommended way is to import your signals module in your app’s config ready() function: my_app/apps.py from django.apps import AppConfig class MyAppConfig(AppConfig): name=”my_app” def ready(self): import my_app.signals my_app/__init__.py default_app_config = … Read more
If you really want to use signals to achieve this, here’s briefly how, from django.db.models.signals import post_save from django.dispatch import receiver class TransactionDetail(models.Model): product = models.ForeignKey(Product) # method for updating @receiver(post_save, sender=TransactionDetail, dispatch_uid=”update_stock_count”) def update_stock(sender, instance, **kwargs): instance.product.stock -= instance.amount instance.product.save()
I ran into this same problem myself. This is caused by a quirk in how transactions are handled in the newer versions of Django coupled with a unittest that intentionally triggers an exception. I had a unittest that checked to make sure a unique column constraint was enforced by purposefully triggering an IntegrityError exception: def … Read more
Save/delete signals are generally favourable in situations where you need to make changes which aren’t completely specific to the model in question, or could be applied to models which have something in common, or could be configured for use across models. One common task in overridden save methods is automated generation of slugs from some … Read more
When you save a model via admin forms it’s not an atomic transaction. The main object gets saved first (to make sure it has a PK), then the M2M is cleared and the new values set to whatever came out of the form. So if you are in the save() of the main object you … Read more