OK . I take on board point 1.... As for point two... I commented the ManufacturerViewset and the references to it in urls.py ,then when i run the url that I believe only looks at ManufacturerModelViewSet i get the following error:
Could not resolve URL for hyperlinked relationship using view name "manufacturer-detail". You may have failed to include the related model in your API, or incorrectly configured the `lookup_field` attribute on this field. This message seems to be quite clear actually?... I can only guess Django is working by convention here (behind the scenes) in that because the Viewset exposes a Manufacturer field that is within the model a ForeignKey field it is utilising the relevant Viewset to try and obtain the data it requires to set up the Hyperlinked Manufacturer field? It seems a bit 'magical' but not beyond the realms of possibility. I am using a browser and I am using the DebogToolbar which I would be totally lost without! 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/a1eb4fdd-c682-446d-97c8-d070cd5685f4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
