*SOLVED:*
The correct method name is *formfield_for_manytomany * instead of
*formfield_for_many_to_many*
*def formfield_for_manytomany(self, db_field, *args, **kwargs):*
*formfield = super(ClusterAdmin,
self).formfield_for_manytomany(db_field, *args, **kwargs)*
*if db_field.name
On Sun, May 17, 2015 at 4:20 PM, Erik Cederstrand wrote:
>
> I just noticed you have a typo:
>
> if db_field.name in ['cluster', ...
>
> should be:
>
> if db_field.name in ['clusters', ...
>
> according to your model definition.
>
>
Thanks Erik. Yes, that was a typo. Unfortunately fixin
> Den 15/05/2015 kl. 20.54 skrev Timothy W. Cook :
>
> def formfield_for_many_to_many(self, db_field, *args, **kwargs):
> formfield = super(ClusterAdmin,
> self).formfield_for_many_to_many(db_field, *args, **kwargs)
> if db_field.name in
> ['cluster','dvboolean','dvuri','dvstri
On Sat, May 16, 2015 at 5:27 PM, Erik Cederstrand wrote:
>
> > Den 15/05/2015 kl. 20.54 skrev Timothy W. Cook :
> >
> > def formfield_for_many_to_many(self, db_field, *args, **kwargs):
> > formfield = super(ClusterAdmin,
> self).formfield_for_many_to_many(db_field, *args, **kwargs)
>
> Den 15/05/2015 kl. 20.54 skrev Timothy W. Cook :
>
> def formfield_for_many_to_many(self, db_field, *args, **kwargs):
> formfield = super(ClusterAdmin,
> self).formfield_for_many_to_many(db_field, *args, **kwargs)
> if db_field.name in
> ['cluster','dvboolean','dvuri','dvs
On Fri, May 15, 2015 at 7:25 AM, Erik Cederstrand wrote:
>
> > I wonder if there is another approach that I can use to solve this?
>
> Does the suggestion to append select_related() / prefetch_related() to the
> queryset in your admin view not work?
>
If I implemented it correctly, it doesn't h
> Den 14/05/2015 kl. 22.19 skrev Timothy W. Cook :
>
> That is exactly the problem Simon. Everyone of those models reference a
> model called Project. I did this so that when the items are displayed in the
> selects, the user knows which project it is from. In the interim I guess
> I'll rem
That is exactly the problem Simon. Everyone of those models reference a
model called Project. I did this so that when the items are displayed in
the selects, the user knows which project it is from. In the interim I
guess I'll remove the call to Project from the __str__
I wonder if there is ano
The last example should read:
if db_field.name == 'baz':
Le jeudi 14 mai 2015 11:14:24 UTC-4, Simon Charette a écrit :
>
> It's a bit hard to tell without your model definition and the executed
> queries but is it possible that the string representation method (__str__,
> __unicode__) of one
I meant
if db_field.name == 'bars':
Sorry for noise...
Le jeudi 14 mai 2015 11:15:49 UTC-4, Simon Charette a écrit :
>
> The last example should read:
>
> if db_field.name == 'baz':
>
>
>
> Le jeudi 14 mai 2015 11:14:24 UTC-4, Simon Charette a écrit :
>>
>> It's a bit hard to tell without your m
It's a bit hard to tell without your model definition and the executed
queries but is it possible that the string representation method (__str__,
__unicode__) of one the models referenced by a M2M access another related
model during construction?
e.g.
from django.db import models
class Foo(mo
It isn't that the individual queries are very slow. But that there are so
many of them. Attached is a screenshot of DjDT.
I see that I am not using a cache at all. This was after doing a reload of
the same standard Django admin/change_form.html.
On Wed, May 13, 2015 at 1:58 PM, Tim Graham wrote
Are you sure it's the query that's slow and not the template rendering
and/or JavaScript performance?
On Wednesday, May 13, 2015 at 12:32:50 PM UTC-4, Timothy W. Cook wrote:
>
> I have a model with 13 M2M relations and some of those have a few thousand
> instances.
> This renders rather slowly
I have a model with 13 M2M relations and some of those have a few thousand
instances.
This renders rather slowly in the Admin.
Thinking about improvements I wonder if it will help to setup
prefetch_related queries
https://docs.djangoproject.com/en/1.8/ref/models/querysets/#prefetch-related
inside
14 matches
Mail list logo
