Google Code offered in: English - Español - 日本語 - 한국어 - Português - Pусский - 中文(简体) - 中文(繁體)
You can delete your app, but App Engine provides safety measures to prevent inadvertent deletion. To delete your app, you first disable it, which stops all serving requests but leaves your data and state alone. Once your app is disabled, you can leave it that way, or you can delete it. While your app is disabled, you can still use the Administration Console to manage it. If you delete it, your data and state are destroyed and can't be restored. Even after your application is deleted, its application ID is reserved.
Warning: Disabling your application does not automatically disable billing. If you disable your app but do not disable billing, your app can continue to incur billing costs even though it is disabled.
To delete your app, go to the Administration Console and click Application Settings on the left side under Administration. Then, click Disable Application, and on the next screen, Disable Application Now. This disables your app. While your app is disabled, it won't serve requests. To continue with deleting your app, click Request Permanent Deletion. After a mandatory 72-hour waiting period, your app will be deleted. To stop the pending deletion, go back to the Application Console, click Application Settings, then Manage Disabled Status, and then Revert Deletion Request.
If billing is enabled for your app, you must disable billing before you can delete the app. See the Billing FAQ for general information about billing.
Any of an app's developers can request deletion of the app, but all developers are notified by email and any developer can revert the request for deletion. If an app is deleted, the developer who requested deletion (who is not necessarily the app's creator) receives a "credit" and can then create one additional app. All developer accounts start with the ability to create 10 apps.
The Administration Console includes a page that shows you statistics for entities in your app's Datastore. To see this page, click Statistics on the left side, under Datastore. The Statistics page displays your data in various ways:
By default, the pie charts display statistics for all entities. You can restrict the pie charts to a particular entity kind by choosing from the drop-down menu. The "Metadata" property type represents space consumed by storing properties inside an entry that is not used by the properties directly. The "Datastore Stats" entity, if any, shows the space consumed by the statistics data itself in your datastore.
The statistics data is stored in your app's datastore. To make sure there's room for your app's data, Google App Engine will only store statistics if they consume less than 1 megabyte; otherwise, you won't see any statistics. If your app's stats go over the 1 megabyte limit, any previously reported statistics will remain. There's no way to tell if this has happened to your app, but if you have a lot of data and you're not seeing any statistics, or any updated statistics, this could be the problem. This problem will be addressed in a future version of App Engine.
The space consumed by the statistics data increases in proportion to the number of different entity kinds and property types used by your app. The more different entities and properties used by your app, the more likely you are to reach the 1 megabyte limit.
For information on accessing datastore statistics programatically, see the Python and Java documentation on that subject.
App Engine applications can gracefully degrade during schedule maintenance periods by handling special Capability errors.
For more information, see the Python and Java documentation on graceful degradation during scheduled maintenance.
Currently, the HRD Migration Tool does not support copying data from Blobstore. If you use Blobstore, you need to manually copy that data over.
There might be some app changes recommended for an optimal migration from a master/slave app to an app that uses HRD. For more information, see the following:
You must make a new copy of that app, deploy the new app, and copy data from your old app to the new deployed copy. You do not incur any billing costs when you do this migration.
Here is the overall process:
Note: Deploy your HRD application before copying data to it. If you start copying data before deploying your application, all of the indexes must be rebuilt.
Note: These instructions use the Duplicate Application Settings feature inside the Application Settings tab of the admin console to copy an app where the copy will use HRD. You could manually accomplish the same thing using other capabilities of the admin console if you wish, but the method described here is the fastest, easiest way to duplicate your app.
To make a copy of your existing app,
-hrd
suffix. You can use this or provide an entirely new application ID if you wish.Note: The use of this tool requires you to first complete the process described in Duplicating Your Application.
The HRD migration tool can migrate your app while your app continues to serve requests and write data to the master/slave datastore. Requests coming in to your app continue to be served by the current app using master/slave during this process, until the copy process is finished and you are ready to switch over to the HRD app. There may be a brief period of time during the switchover when your application may not be able to serve write requests.
Here is the overall process:
The migration tool provides a status monitor indicating progress and a time estimate. In addition, you can request an email to be sent to you when the migration tool finishes the current run.
Note: Deploy your HRD application before copying data to it. If you start copying data before deploying your application, all of the indexes must be rebuilt.
To run a migration,