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 > <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/a1eb4fdd-c682-446d-97c8-d070cd5685f4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
