Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>To accomplish this you need to customize your Varnish VCL to handle <code>PURGE</code> requests and your Plone CMS so that it issues a purge request to Varnish when content is changed.</p> <p>Plone Developer Documentation has pretty good and thorough documentation on <a href="http://developer.plone.org/hosting/varnish.html" rel="nofollow">using Varnish with Plone</a>. You can adapt it to your specific needs.</p> <p>The example in the documentation explains how to create a custom ACL and regexp purge handling in VCL, and then how to use that in Plone to purge the entire cache. I have copied the VCL and Plone view from the examples here, just in case they get removed from the Plone site some time in the future:</p> <pre><code>acl purge { "localhost"; # XXX: Add your local computer public IP here if you # want to test the code against the production server # from the development instance } ... sub vcl_recv { ... # Allow PURGE requests clearing everything if (req.request == "PURGE") { if (!client.ip ~ purge) { error 405 "Not allowed."; } # Purge for the current host using reg-ex from X-Purge-Regex header purge("req.http.host == " req.http.host " &amp;&amp; req.url ~ " req.http.X-Purge-Regex); error 200 "Purged."; } } </code></pre> <p>Then for Plone you create a custom view for issuing <code>PURGE</code> requests to Varnish:</p> <pre><code>import requests from Products.CMFCore.interfaces import ISiteRoot from five import grok from requests.models import Request class Purge(grok.CodeView): """ Purge upstream cache from all entries. This is ideal to hook up for admins e.g. through portal_actions menu. You can access it as admin:: http://site.com/@@purge """ grok.context(ISiteRoot) # Onlyl site admins can use this grok.require("cmf.ManagePortal") def render(self): """ Call the parent cache using Requets Python library and issue PURGE command for all URLs. Pipe through the response as is. """ # This is the root URL which will be purged # - you might want to have different value here if # your site has different URLs for manage and themed versions site_url = self.context.portal_url() + "/" headers = { # Match all pages "X-Purge-Regex" : ".*" } resp = requests.request("PURGE", site_url + "*", headers=headers) self.request.response["Content-type"] = "text/plain" text = [] text.append("HTTP " + str(resp.status_code)) # Dump response headers as is to the Plone user, # so he/she can diagnose the problem for key, value in resp.headers.items(): text.append(str(key) + ": " + str(value)) # Add payload message from the server (if any) if hasattr(resp, "body"): text.append(str(resp.body)) </code></pre> <p>As mentioned, this simply purges the entire cache on demand. I am no expert in Plone, so I'm unable to give you a detailed answer on how to adapt this to purging just specific content. Basically you need to determine which pages you need to purge in specific cases, and then adapt the example above to automatically issue a <code>PURGE</code> request to Varnish when <code>POST</code> requests are handled in Plone.</p> <p>Handling purging in VCL alone (i.e. detecting POST calls and purging content based on those) is quite complex. I believe it'll be much more efficient handling the logic and purging in Plone.</p> <p><strong>Update:</strong></p> <p>If you wish to purge the entire cache on every <code>POST</code>, this can be accomplished as follows.</p> <pre><code>sub vcl_recv { if ( req.request == "POST") { ban("req.http.host == " + req.http.Host); return(pass); } } </code></pre> <p>Now every <code>POST</code> request causes ALL pages that have been cached under the same hostname to be purged from the cache. I recommend looking into the earlier solution in a long run though. It is much more efficient purging only the pages that actually need to be purged when a <code>POST</code> occurs.</p>
    singulars
    1. This table or related slice is empty.
    1. POVarnish: Clear Cache after POST data
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USKetola
    1. USKetola
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POVarnish: Clear Cache after POST data
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTBountyClose
    1. COThanks for your answer @Ketola . Is there a way I can purge the entire cache everytime I receive a POST request?
      singulars
      1. PO
      1. USFrankline
    2. COIndeed there is. I have updated my answer to cover this alternative as well. It is not a very efficient solution though, and your cache hit rate will never be very high in this case.
      singulars
      1. PO
      1. USKetola
    3. COThat should serve my purpose for now.
      singulars
      1. PO
      1. USFrankline
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload