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
Related
I thought of using localStorage as it will support pc browsers as well as mobile applications
but i am not sure whether it will serve my purpose or not.
LocalStorage is the way to go. It persists information without expiration date, presumably forever, or until the user unistalls the app or erases the application data. Check out w3schools documentation for some good examples to get started.
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.
We need to migrate some data in our users documents, which we are accessing through Google Drive's Realtime API. We don't want them to undo the change, since that would take the document back to a format that our application no longer understands. I know we could refresh the page, and that would clear the undo stack, but is there a more targeted way of preventing them from undoing that change?
This is not currently possible. Its been a frequent feature request though, so we are looking at adding support for it.
I have created a small project in Google apengine and like it apart from one thing: It seems virtually impossible to delete or change an endpoint, once it has been made. The API often stays the same, regardless of code changes in the java endpoint classes. I tried to delete the complete API, but that is not possible either. Is there any way to do this?
RE: Deletion
it's not currently supported, but we're working on it.
RE: API Changes
The Google APIs Explorer web app aggressively caches, so you'll need to clear your cache or force a refresh when you update your API server side to see the changes in the client.
I'd like to disable user access to my app so that I can perform a schema migration. I've looked into a few possibilities and found possible shortcomings:
Disable datastore writes - I'd rather just bring my whole application down so that people do not see any errors, etc. Also, I assume disabling writes will prevent me from performing the migration.
Disable the application - It's not clear to me that this would disable it only for my users, leaving me unable to perform the migration. I am also unsure of the disable/enable turnaround time.
Redirect my domain name to a temporary page - my app would still be accessible on appspot.com
Upload a new version of my app that doesn't respond to requests other than to direct to a "temporarily down" page.
Any suggestions?
Suggestion number 4 seems like probably the best way to do this. Some frameworks have a "maintenance mode" in which all incoming requests would be redirected to a page indicating the site is down due to maintenance. If your framework doesn't support such a mode, you can just upload a new version of your app (maybe call the version maintenance) and switch to that as your new default version. This version could be an empty app in which all incoming requests are turned to a "maintenance page" indicating the site is down for maintenance. Then manually go to the version of your app with the migration code and execute it (http://<version>.<appname>.appspot.com). Switch your apps default version to the new version with the new schema when you're done with the migration.
Explanation of your other ideas
Disabling writes would prevent even you from making writes on the application. I believe this was more meant for migrating from one app to another or other applications of "freezing" the datastore.
Disable the application would bring the app down entirely
Redirecting your domain would inflict a DNS lag on your migration, something that can take 48 hours to fully propagate each way (switching to the temporary page, then switching back to the new version)
As aforementioned, IMHO this would be the best way to do it.
Is it not possible to use both schema's, and use a new version of your app to migrate, which only uses the new schema. In this way you can always fall back to your old version.
By the way. Because the datastore is schema-less, It was always possible for me to change the "schema", without bringing the app down.
Go to GCP > App engine > Settings > Disable application.
You can sure enable your application ay any time.
If you disable this app, a few things will happen:
The app will stop serving
All data and state will be saved
Billing charges will still incur when applicable
Your task queues will continue to run. They can be paused in the Cloud Tasks UI