Two Django gotchas recently uncovered in addons-server

[mpil...@mozilla.com]

We recently found these Django-related gotchas while working on AMO server-side code (https://github.com/mozilla/addons-server) and thought it'd be useful to share them.

1) Signals don't play well with deferred fields on models in < 1.10

When you use .defer() or .only() and then save a model instance that was loaded with deferred fields, in certain circumstances Django < 1.10 will not use the actual model name for the sender parameter of the signal, and instead use the dynamic name, which looks like "ModelName_Deferred_field". This is a problem because callbacks are supposed to be connected using that sender parameter, so that bug causes those callbacks never to be triggered.

This was fixed in 1.10 because the way deferred fields works was changed. Our workaround was to avoid defer() when we know there is going to be a save() later in the code with that same instance.

2) get_object_or_404 uses the default manager, not necessarily "objects"

This one is more specific to our own code, but still useful to be aware of. We have a quite subtle setup of managers on our models in addons-server, because we soft-delete addons by setting a specific field on them and filtering on that field in the "objects" manager. In order not to break relations though, we have another "unfiltered" manager, defined before "objects".

It may sound obvious, but get_object_or_404(Model, ...) does not use "objects", and instead uses the first manager. In some of our views meant for developers, where there is almost no additional filtering, we were not careful about that and that allowed developers to access deleted add-ons.

The fix is simple: use get_object_or_404(Model.objects, ...) instead.


Hope that's useful !