python - Tastypie DB level Field Selection -

given postgresql 9.2.10, django 1.8, python 2.7.5 , django-tastypie 0.12.1:

i trying figure out how dynamic queryset tastypie based off of custom param (field selection) end user may filter via this:

https://example.com/api/v1/resource/?fields=field1 (list view)
https://example.com/api/v1/resource/1/?fields=field1 (detail view)

def dehydrate() (not using):
implementing in dehydrate fine, since data has been 'dehydrated' gain achieve response smaller in size due removing unselected fields. code here.

def full_dehydrate() (currently using):
implementing in full_dehydrate better, skipping initial 'dehydate' on fields did not select. faster , more effecient dehydrate method above. code here.

these 2 methods not implement filter @ db level though (i still doing model.objects.all()). fine in dev instance db more local application/api itself, in prod (in case) db on separate server. question this, there way can dynamically change tastypie query filter given resource based off of params passed in api request? get_object_list looks promising unsure if method pursue or if should writing custom filter add in via build_filters (i assuming build_filter better,, though every example see custom build filters requires appy_filter reason.). unsure particular scenario, method used request params bundle.request not present in these 2 methods.

thank took time read , huge provides working solution. appreciate , thought process behind answers given.

** edit 1 **
here visualization of process in filter need occur (hopefully helps stimulate idea's)

** tl;dr **
want allow db level filtering of tastypie resrouce queryset based off custom param end user may use (if not used tastypie should behave normally) in api request (read: dynamically modify resource queryset).

it seems want set specific fields on generated django select clause. happen need use only() , defer() methods django's queryset. use of 1 or depends uniquely on needs.

now, need call methods on queryset before items accessed. tastypie resource's build_filters() useless in case because has arguments queryset's filter() receiving. apply_filters() sounds nice option, not place there because not modifying filtering (where) selection (select). respective modification in obj_get_list(), after apply_filters() call.

i providing gist should fit needs here. explained in gist:

this has done in 2 parts:

1) in model queryset database selection. need in code section queryset ready, still not evaluated. obj_get_list , obj_get perfect tastypie requests.

2) in full_dehydrate method, prevent tastypie fetching fields model.

the gist dehydrate() propose not seem necessary, full_dehydrate() picking selected fields.

note: record, using only() or defer() on queryset, , later trying access unselected field on model causes individual sql call requested field. careful select needed fields, specially in list of objects, because not doing generate n*m calls being n number of unselected fields later-accessed , m number of objects queried. justification full_dehydrate() gist modification.