No more zip hacks to get all the many files up for Django 1.0 to run on Google AppEngine. GAE now support Django 1.0. You still have to use Google Bigtable models as there is no translation that converts from Django models to Google Bigtable models but 1.0 is so much better to have than .96.

I hope this is a start of supporting and keeping up to date many versions of Django, the Python runtime and common libs so that the 1000 file limits can be used solely for applications running not all the libraries needed.

UPDATE: on the issue for adding Django 1.0 Guido chimed in on 1.1 support when it is out of beta and a nice switch that allows you to choose the django version, hooray! Maybe a python version selector and other libraries soon…

use_library('django', '1.0')

It's indeed fixed, though not yet documented.

To use:

1. Install Django 1.0 into the Python version you're using with the SDK (usually the
system Python).

2. In your app:
from google.appengine.dist import use_library
use_library('django', '1.0')

You no longer need to copy Django 1.0 into your app, nor do you need to mess with
sys.modules, sys.path and zipfiles.  (Though those instructions still apply if you
want to use Django 1.1 -- we'll start supporting that once it's out of beta.)

Note, Django 0.96 is still the default, and can also explicitly be requested by using
use_library('django', '0.96') -- in API v2, we'll probably change things so you
*have* to specify a Django version before you can use it.

We're contemplating the support of other open source packages as well (as long as
they don't contain C code).

Google AppEngine now runs Python AND Java

It is still in beta but select developers are being added and developers allowed in will be expanded, I got in as I made the request so it looks like it is still filling up.

Both Java and C# were top requests on AppEngine desired languages/platforms.  They have low level support for specific Google features and infrastructure and wrappers around these features to mimic common java libraries like JPA, JCache and java.net around google urlfetch.  So it is still a bit locked to the platform or changes will need to be made to run on Google AppEngine and other environments.  

Many of the changes made to apps really are due to the scalable nature of the cloud architecture without such things as joins and limits on bulk processing, but in the end these points are really better for scalability from the start.  As for being locked to a platform we are already seeing copies such as AppScale that is an open source implementation of Google AppEngine.  So software architecture, data architecture and how we prepare for the terabytes upon terabytes of shared data in the future might be changing. 

Some unsupported features of major Java libraries…

java.net Features Not Supported

• The URL Fetch service does not support persistent HTTP connections. When the app accesses response data using the URLConnection object, App Engine calls the URL Fetch service to complete the request. After the response data has been accessed, the request data cannot be modified.
• The app cannot set explicit connection timeouts for the request.

Unsupported Features of JPA

The following features of the JPA interface are not supported by the App Engine implementation:

• Owned many-to-many relationships, and unowned relationships. You can implement unowned relationships using explicit Key values, though type checking is not enforced in the API.
• “Join” queries. You cannot use a field of a child entity in a filter when performing a query on the parent kind. Note that you can test the parent’s relationship field directly in query using a key.
• Aggregation queries (group by, having, sum, avg, max, min)
• Polymorphic queries. You cannot perform a query of a class to get instances of a subclass. Each class is represented by a separate entity kind in the datastore.

JCache Features Not Supported

• The JCache listener API is partially supported for listeners that can execute during the processing of a app’s API call, such as for onPut and onRemove listeners. Listeners that require background processing, like onEvict, are not supported.
• An app can test whether the cache contains a given key, but it cannot test whether the cache contains a given value (containsValue() is not supported).
• An app cannot dump the contents of the cache’s keys or values.
• An app cannot manually reset cache statistics.
• Asynchronous cache loading is not supported.
• The put() method does not return the previous known value for a key. It always returns null.

High Level Cloud Provider or Low Level Cloud Provider?

With other cloud providers like Amazon EC2, Mosso, SliceHost and others you can choose your platform.  But Google has an amaxing infrasturcture and taking advantage of BigTable and automatic scaling is nice expecially with a 300MB transfer free quota per app.  There are probably times when each type of provider might be beneficial, lower level like Amazon or higher level like Google AppEngine.

View the announcement here at Google AppEngine Blog which has other great news with the launch:

• Access to firewalled data: grant policy-controlled access to your data behind the firewall.
• Cron support: schedule tasks like report generation or DB clean-up at an interval of your choosing.
• Database import: move GBs of data easily into your App Engine app. Matching export capabilities are coming soon, hopefully within a month.

Google AppEngine is a fun environment to develop for.  AppScale is an open source implentation of Google AppEngine that can be used on your own equipment.  This new software project works on Amazon’s  AWS and EC2 platforms and the open source version of that in Eucalyptus.

Cloud based architectures I believe will be more mainstream and used for development even if on self-hosted environments because the data architecture is setup for maximum horizontal scalability from the beginning.  BigTable, SimpleDB, HBase, even couchDb type databases will become more prevalent as we move into terabytes and terabytes of data.  Data is growing at an alarming rate and this is a natural software evolution to address that.

Great video from Google on building for scale in Google AppEngine. The cloud by nature gives you upwards scaling easily but the data structures and techniques to get data efficiently is much different than RDBMS type optimization. Therefore the more experience and information you can gain on this topic will help you in the future when terabytes of data is the norm.

The slides from the video