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
> <conradj...@googlemail.com <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 django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
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.
