Closed DanielSwain closed 4 years ago
Interesting. I'd like to understand this but I'm a little confused. If you have a reproducible example, that'll help.
So the overridden save
was calling the original save
, right? Did you have depth >= 2
in order to have PySnooper track there?
Can you share the PySnooper output?
Was not aware of depth >= 2
. That provides what we need. Thanks for the quick response.
For reference, here is a Stack Overflow answer we found prior to trying PySnooper that helped us solve this problem. The person who asked the question had the same problem come up that we did because of calling super(Model, self).save(*args, **kwargs)
two times in the overridden save()
.
Another day saved :joy:
We just came across an error in an overridden
save()
that was not present in the Django admin but that cropped up when creating a front-end with DRF. Turned out there was akwarg
that needed to have have its value changed:force_insert
had to be changed toFalse
becausesuper
was being called two times in the overriddensave
routine (yes, it had to be called two times in order to first save a file that was being uploaded). PySnooper DID show the value ofkwargs
whenforce_insert
was explicitly set to False within the overriddensave()
, but it did NOT show the value ofkwargs
when the error occurred in thesave()
and thekwargs
were not touched. If the value ofkwargs
had been shown automatically from within thesave()
, it would have been an immediate tipoff to how to remedy the error.