Ohh. Yup. My bad :)
On Wednesday, November 12, 2014 5:01:03 PM UTC-5, Peter Sagerson wrote:
>
> I agree that setting self.exclude will set the instance attribute, thus
> hiding the class attribute of the same name. However, it appears that a
> given AdminSite instantiates each registered
> Your analysis is entirely correct, as far as I can tell. Setting
> attributes on `self` in a per-request method of a `ModelAdmin` is not
> concurrency-safe, and it should not be recommended or demonstrated in
> the docs. If you'd be willing to file a bug (or, better, a PR) to fix
> this
Hi Peter,
On 11/12/2014 10:59 PM, Peter Sagerson wrote:
> I agree that setting self.exclude will set the instance attribute,
> thus hiding the class attribute of the same name. However, it appears
> that a given AdminSite instantiates each registered ModelAdmin once
> at registration time.[1] The
I agree that setting self.exclude will set the instance attribute, thus hiding
the class attribute of the same name. However, it appears that a given
AdminSite instantiates each registered ModelAdmin once at registration time.[1]
The default AdminSite itself is a module global. Thus, any
On Tuesday, November 11, 2014 3:24:48 PM UTC-5, Peter Sagerson wrote:
>
> The documentation of ModelAdmin.get_form()[1] demonstrates modifying
> self.exclude in order to modify the add/change form on a per-request basis.
> However, looking at django.contrib.admin, it seems clear that ModelAdmin
The documentation of ModelAdmin.get_form()[1] demonstrates modifying
self.exclude in order to modify the add/change form on a per-request basis.
However, looking at django.contrib.admin, it seems clear that ModelAdmin is
instantiated when it's installed, not for every request. It also doesn't
6 matches
Mail list logo
