Are there any docs on how to flush the google app engine memcache using Go?
I can see flush_all() in the python docs https://developers.google.com/appengine/docs/python/memcache/functions
The memcache go code lists a flush function, which is not listed in the official docs. I suspect it works and is just undocumented.
Related
I read all the Pub/Sub docs and saw no mention of Snapshots.
But when I read the docs for the Node.js Client Libraries, I find references to Snapshot objects: https://googlecloudplatform.github.io/google-cloud-node/#/docs/pubsub/0.11.0/pubsub/snapshot
Huh?
It's an invite-only feature that seems to provide some sort of replayability functionality https://cloud.google.com/sdk/gcloud/reference/alpha/pubsub/.
My application checks user authentication and authorization on every request and I am thinking of moving the authentication and authorization data from datastore to memcache.
Is memcache suitable for this usecase? Is it secure or I should not do it?
Yes, Memcache is secure. If you save important content to Memcache you have to back it up on datastore because it can be evicted at any moment. There are datastore APIs on Python (NDB) and Java (Objectify) that manage the cache for you automatically, but I'm not sure about Go.
If your users log in with their Google Account you can use the Users API1.
Yes, memcache is secure as the marked answer says (even shared memcache).
However as one comment says, you should really not reinvent appengine sessions, and instead use them. Google for "appengine go sessions" and you will find resources about it. The first link in that search:
https://godoc.org/code.google.com/p/sadbox/appengine/sessions
shows you how to use them in Go.
Besides handling the memcache and datastore implementation, it has additional features like configurable expiration.
I've flushed memcache using flush_all() and by hitting the Flush Cache button in my deployed app Memcache Viewer, however the statistics are not resetting. Is there anyway to reset the statistics?
Other than those two options, no. If you believe that this is a bug (or feature request), please file one in the issue tracker.
I am working on a project on Google AppEngine, where I am using the datastore and memcache. For testing purposes, I go to the control panel, change and save of some values of some saved entities in the datastore. However, since they're already in memcache, I assume, the changes don't reflect on the application.
Using Admin/control panel, is there a way to enforce reloading these entities into memcache from the datastore, or at least to clear memcache?
Thank you,
Hazem
With the release of SDK 1.6.4 today a memcache page has been added to the production admin dashboard. It has a button that lets you flush memcache (as well as other features).
That does not solve the problem of automatically managing the memcache version of your entities. For that you could look into the NDB library (new standard library in SDK 1.6.4) which automatically caches your entities as you use them and invalidates the cache as necessary. It has lots of other features as well. I have not used it yet but it certainly sounds good: http://code.google.com/appengine/docs/python/ndb/
UPDATED March 27 now that SDK 1.6.4 has gone final and I can confirm it contains the memcache control panel.
As an alternative: I believe you could use Remote API, fire up a shell and execute e.g. memcache.flush_all()
no there isnt.
make a handler that does that for you and when you need to flush memcache you can simply hit that url
In http://blog.notdot.net/2010/09/Under-the-hood-with-App-Engine-APIs, it explains how you can perform an asynchronous datastore get request. I want to perform an asynchronous put request.
How do I do that?
Thanks!
As of GAE 1.5.0 there is 'put_async'.
Your best option for doing asynchronous calls to the datastore at the moment is to use Guido's experimental NDB project, which is a reworking of the App Engine datastore API to support asynchronicity.
My blog post was intended to be instrucitonal, but not as a template for something to do directly - reaching down to that level of the code to do asynchronous requests is likely to be very involved and awkward, and you're much better using a library that does it for you, like NDB.