4 ms·

1. You can still use transactions with Django-nonrel. Just use App Engine's run_in_transaction() function in combination with Django models. No problem. 2. The

1. You can still use transactions with Django-nonrel. Just use App Engine's run_in_transaction() function in combination with Django models. No problem. 2. The slow startup problem doesn't really matter, anymore, because App Engine provides reserved instances and warmup requests. It only matters to those who don't want to pay a few $ for reserved instances (but even without reserved instances there are ways around that ;).

StavrosK 16y ago
That's what I thought too. I wonder if this means that Django is (or will be, when it's mature enough) a very good alternative for GAE. A memcache caching module would be especially useful, as it would enable the entire Django caching infrastructure to work on GAE.
- wkornewald 16y ago
  Caching is already pre-configured (in default settings) to use GAE's memcache in djangoappengine/Django-nonrel. The session app is also pre-configured to use cache+db. Django's mail API also is pre-configured to use GAE's mail API via a special backend. Even file uploads work with FileField if you use django-filetransfers. A large part of Django already works out-of-the-box and it's easy to write fully portable code. With django-dbindexer you can even use QuerySet features which are not natively supported by App Engine. At some point django-dbindexer will even support JOINs via automatic denormalization (or via in-memory filtering where desired) and maybe also simple aggregates and scalable counters (via QuerySet.update()). This will simplify complex DB code a lot (compared to App Engine's model API) and by reusing Django's ORM as the abstraction for common NoSQL patterns you can not only move between NoSQL DBs, but also between SQL and NoSQL (at least to a certain extent; the goal is to provide a better high-level NoSQL API and only implement scalable features, not build a SQL emulation layer that wouldn't scale).

StavrosK 16y ago

That's what I thought too. I wonder if this means that Django is (or will be, when it's mature enough) a very good alternative for GAE. A memcache caching module would be especially useful, as it would enable the entire Django caching infrastructure to work on GAE.

wkornewald 16y ago
Caching is already pre-configured (in default settings) to use GAE's memcache in djangoappengine/Django-nonrel. The session app is also pre-configured to use cache+db. Django's mail API also is pre-configured to use GAE's mail API via a special backend. Even file uploads work with FileField if you use django-filetransfers. A large part of Django already works out-of-the-box and it's easy to write fully portable code. With django-dbindexer you can even use QuerySet features which are not natively supported by App Engine. At some point django-dbindexer will even support JOINs via automatic denormalization (or via in-memory filtering where desired) and maybe also simple aggregates and scalable counters (via QuerySet.update()). This will simplify complex DB code a lot (compared to App Engine's model API) and by reusing Django's ORM as the abstraction for common NoSQL patterns you can not only move between NoSQL DBs, but also between SQL and NoSQL (at least to a certain extent; the goal is to provide a better high-level NoSQL API and only implement scalable features, not build a SQL emulation layer that wouldn't scale).