Page and Site SQL Gets Triggered with View Level Caching

20 views
Skip to first unread message

Matt Mansour

unread,
Jul 24, 2019, 12:05:19 PM7/24/19
to Mezzanine Users
Hi All, 

I am caching an endpoint at the view level and I noticed there are still two sql calls being made for the Site and Page objects, after the below response is cached .

class CampaignDetail(APIView):
 
@method_decorator(cache_page(10))
 
def get(self, request, version, campaign_key):
 campaign
= Campaign.objects.select_related('product').get(campaign_key=campaign_key)
 data
= {
 
"active":"true",
 
"deal-price": "20.00",
 
"daily-limit-reached": campaign.daily_limit_reached(),
 
"keywords": campaign.get_campaign_keyword(),
 
"product-asin": campaign.product.asin,
 
"product-name": campaign.product.product_name,
 
"product-price": "{}".format(campaign.product.price)
 
}

 
return Response(data)

Campaign subclasses TimeStamped (not Displayable), so I am wondering why the following SQL still gets called upon refresh during the cache period:

SELECT"django_site"."id", "django_site"."domain", "django_site"."name"FROM "django_site" WHERE UPPER("django_site"."domain"::text) = UPPER('localhost:8000')

And 

SELECT"pages_page"."id", "pages_page"."keywords_string", "pages_page"."site_id", "pages_page"."title", "pages_page"."slug", "pages_page"."_meta_title", "pages_page"."description", "pages_page"."gen_description", "pages_page"."created", "pages_page"."updated", "pages_page"."status", "pages_page"."publish_date", "pages_page"."expiry_date", "pages_page"."short_url", "pages_page"."in_sitemap", "pages_page"."_order", "pages_page"."content_model", "pages_page"."parent_id", "pages_page"."in_menus", "pages_page"."titles", "pages_page"."login_required"FROM "pages_page" WHERE ("pages_page"."site_id" = 1 AND ("pages_page"."publish_date" <= '2019-07-24T15:26:59.395377+00:00'::timestamptz OR "pages_page"."publish_date" IS NULLAND ("pages_page"."expiry_date" >= '2019-07-24T15:26:59.396055+00:00'::timestamptz OR "pages_page"."expiry_date" IS NULLAND "pages_page"."status" = 2 AND "pages_page"."slug" IN ('api', 'api/v1', 'api/v1/campaign/a8b7ea62-79d0-4ee4-8f62-81fcde54ea32', 'api/v1/campaign')) ORDER BY "pages_page"."slug" DESC

I'd like to avoid all db hits if possible. Does anyone see what I am doing wrong or if there is a bug here? 

Eduardo Rivas

unread,
Jul 24, 2019, 12:37:12 PM7/24/19
to mezzani...@googlegroups.com

Hi Matt.

 

My guess is that Mezzanine’s Page middleware tries to fetch a page on every request (as pages can have any URL). I would try to disable the middlewares you don’t need and see if that works.

--
You received this message because you are subscribed to the Google Groups "Mezzanine Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mezzanine-users/ad008e6c-856b-466a-919e-fa407461a047%40googlegroups.com.

 

Matt Mansour

unread,
Jul 24, 2019, 1:32:11 PM7/24/19
to mezzani...@googlegroups.com
Thanks Eduardo. I'll give it a try. 

Matt Mansour

unread,
Jul 25, 2019, 6:22:14 PM7/25/19
to Mezzanine Users
So far I haven't been able to figure out an approach to easily disable PageMiddleWare that doesn't raise errors. Likewise, removing the mezzanine pages app also raises errors. 

One approach that works is to directly edit the mezzanine PageMiddleWare class. 


def process_view(self, request, view_func, view_args, view_kwargs):
   
if the path != exluded path:
       run the middleware
...
       
return page_view...
   
return None

I wonder short circuiting PageMiddleWare  is needed enough by others to create a setting: a list of excluded paths. e.g. EXCLUDE_PAGE_MIDDLEWARE_URLS = ('api', ....) 

It appears something like this is needed you want to cache api endpoints. 

To unsubscribe from this group and stop receiving emails from it, send an email to mezzani...@googlegroups.com.

Reply all
Reply to author
Forward
0 new messages