It seems Defining the ManufacturerModelSerialiser thus has solved the
problem (which backs up my last mail I think). Its not entirely what I
wanted but it at least gets me down to just doing the 1 Query as I
originally intended, 1 query is always better than 4000 odd!
class ManufacturerModelSerialiser(serializers.HyperlinkedModelSerializer):
Manufacturer = serializers.Field(source='Manufacturer.Name')
class Meta:
model = ManufacturerModel
fields =
('WebSite','LogoLocation','Name','id','Manufacturer','url','SeriesStartDate','SeriesEndDate','SourceUrl','LastChecked')
On Friday, 11 April 2014 15:01:22 UTC+1, Javier Guerra wrote:
>
> On Fri, Apr 11, 2014 at 8:31 AM, Conrad Rowlands
> <[email protected] <javascript:>> wrote:
> > As you can see the queryset is loading all from the database.... What I
> > would prefer to be able to do is to share the first queryset from the
> > ManufacturerModelViewSet (which should have all of the correct fields)
> with
> > the ManufacturerViewSet. I'm guessing this could be achieved by
> overriding
> > get_queryset in my ManufacturerViewSet though I don't know what to do
> from
> > there?
>
>
> first, you shouldn't use ManufacturerModel.objects.all(). in your
> get_queryset(), it should call the superclass' defintion and add the
> select_related() to it:
>
> def get_queryset(self):
> return super(ManufacturerModelViewSet,
> self).get_queryset().select_related()
>
>
> but in this case i guess the result is the same. It's just more
> flexible this way. It also helps to factorize it away in a mixin
> class as I suggested initially.
>
> the queryset returned by this method isn't used as-is; it's first
> passed to the filter_queryset() method.
>
>
> second, if you're talking only about one specific URI that is handled
> by ManufacturerModelViewSet, then it doesn't matter what you have or
> not in other viewset (ManufacturerViewSet); you could even delete it
> and it should still work the same.
>
> to see if it's possible to avoid the second query, first you have to
> know which part of the view requests it. a big help on this is the
> DjangoDebugTollbar. it works perfectly with the RestFramework API
> browser.
>
> Of course, if you're using the browser, remember that it can do extra
> queries to build the user-friendly HTML. those extra queries don't
> pass through your viewset methods, so it's unlikely they would respect
> the filters.
>
> to see what queries you do in production mode, set the logging config
> to report all queries to console or logfiles.
> (https://docs.djangoproject.com/en/1.6/topics/logging/#django-db-backends).
>
> or make the DB server itself log all queries.
>
>
>
> --
> Javier
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/a6480388-b795-457e-a178-9d3377867581%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
