Group items tagged

Thanks to the Task Queue API released in SDK 1.2.3, it's easier than ever to do work 'offline', separate from user serving requests. In some cases, however, setting up a handler for each distinct task you want to run can be cumbersome, as can serializing and deserializing complex arguments for the task - particularly if you have many diverse but small tasks that you want to run on the queue. Fortunately, a new library in release 1.2.5 of the SDK makes these ad-hoc tasks much easier to write and execute. This library is found in google.appengine.ext.deferred, and from here on in we'll refer to it as the 'deferred' library. The deferred library lets you bypass all the work of setting up dedicated task handlers and serializing and deserializing your parameters by exposing a simple function, deferred.defer().

To demonstrate how powerful the deferred library can be, we're going to reprise an example from the remote_api article - the Mapper class. Like the example in the remote_api article, this class will make it easy to iterate over a large set of entities, making changes or calculating totals. Unlike the remote_api version, though, our version won't require an external computer to run it on, and it'll be more efficient to boot!

Task Queue items are limited to 10kb of associated data. This means that when the deferred library serializes the details of your call, it must amount to less than 10 kilobytes in order to fit on the Task Queue directly. No need to panic, though: If you try to enqueue a task that is too big to fit on the queue by itself, the deferred library will automatically create a new Entity in the datastore to hold information about the task, and will delete the entity once the task has been run. This means that in practice, your function call can be up to 1MB once serialized.

You have three options at the moment, when it comes to a 'multi-tenant' app such as you describe: You can have a single app that your customers add to their domains. Your app will have a single datastore, but you can use the Host header to determine which customer is accessing the app, and segregate the datastore entries based on that. Easy to deploy and upgrade Easy for customers to install Users have to have Google accounts, not Apps accounts, to log in. You can deploy a fresh app instance for each customer. Harder to deploy and upgrade More customer involvement required to install Provides firm separation of data Users can log in with their Apps credentials You can work with Google to create a new Apps Marketplace app All the benefits of point 1 and 2, above Requires Google involvement No certain release date yet

We're going to fix this for the App Engine 1.4.0 release. What we'll do is have messages at Log.INFO level be outputted when you've got your Launch Configuration's log level set to INFO. In the Google Plugin for Eclipse, we'll make a change such that any new launch configurations created have a default log level of WARN.