On Sat, Jul 31, 2010 at 4:04 PM, tiemonster <m...@tiemonster.info> wrote: > So anyways... > > Google App Engine is a special case. It is not nearly as robust a > database solution as something like CouchDB or MongoDB - but then > again it was never meant to be. The direction from the beginning was > on scaling, even if it meant dropping features. The BigTable ORM lacks > many of the functions necessary for implementing the Django ORM on > that database. Python-only solutions to these gaps would not scale as > well as low-level database APIs, and as such would probably not scale > well enough to be useful. The situation has not improved because > Google doesn't see a need. App Engine fits in an even more specialized > niche than most NoSQL solutions.
Which features does App Engine's datastore lack that would be necessary for Django's ORM? Why would a Python-only solution not scale well enough? You probably mean it does scale, but it's slightly less efficient because background tasks and map/reduce are handled via requests (it's a distributed system, after all), but the overhead should still be small compared to the DB overhead. What I actually like about GAE's datastore is that it forces you much earlier to think in terms of scalability. MongoDB users might suddenly realize with a 10GB database that something is wrong and needs to be rewritten and migrated. In GAE you normally run into these issues with just a few 1000 entities or earlier. There's only one issue that can show up much later (several 10,000 entities) and I've described it here: http://www.allbuttonspressed.com/blog/django/2010/01/An-App-Engine-limitation-you-didn-t-know-about Unfortunately, GAE's upcoming extended datastore API (the one which is supposed to solve the exploding indexes problem) will use merge-joins more extensively, so that limitation will probably affect more people. > Now django-nonrel is doing some excellent work to try to implement a > workable ORM on App Engine. However, I'm sure they are facing an > uphill battle because of the constraints of the platform. I have no > doubt that they will indeed produce a workable solution in time, > though. Is our current solution not workable for you? What's missing? In our experience, Django's ORM maps pretty well to GAE's API. You can access almost all GAE features via Django's ORM in a portable way. Auth, caching, and sessions work unmodified. Many small reusable apps work unmodified (e.g., django-socialauth, django-openid-auth, etc.). What's left is mostly batch-put and cursors and entity groups. The last one would be easy to add. The first two would ideally get an equivalent in Django's ORM before they're implemented, but it should be possible to provide separate functions for those features, too. I'm just asking because I'm interested in hearing from other people which problems we need to solve to make Django-nonrel and Django's official NoSQL project practical for them. Bye, Waldemar Kornewald -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
