I've never been completely convinced by the idea of hacking the Django ORM to be able to talk to non-relational data stores - if you can't do joins, you lose most of the stuff that makes the ORM useful.
I'd much rather see tools like the Django admin evolve interfaces which can be plugged in to the Django ORM or plugged in to some other backend (PyMongo, CouchDB, SimpleDB, AppEngine DataStore or whatever). That feels to me like a more natural point for an abstraction layer than the core ORM itself.
I agree, it would be nice if Django would develop further abstractions for example for key value stores and document stores, and add functionality to the admin for those.
It looks like our projects will get a new maintainer. So, it's not as bad as it sounds. It's only us leaving the project. Follow the discussion group for more updates:
Oh and sorry for the disgusting site "design". Our site isn't running on Django-nonrel, anymore, and I still didn't get to making a nicer design (not that the previous one was much better ;).
I've built a custom micro-framework and an async ORM based on a few ideas I had while working on Django-nonrel. The result is wonderfully small, simple, and expressive. We're using it at our startup. I'm just trying to bring back the fun of exploring new programming concepts. In this regard, open-source really doesn't work for me.
I used various versions of Django when I first started hacking on Appengine. Eventually I just gave up and switched to Tornado. Why? Django is a large and tightly coupled beast of a framework. It's very likely that a given plugin reaches down to the DB level meaning that it'd have to be manually ported to Appengine.
Every single project which tried to port Django to GAE relied on either monkey patching during runtime or forking the codebase. This was an enormous amount of work as you can imagine, and the benefits grew smaller and smaller as simpler frameworks became available.
Now don't get me wrong, I'm not ragging on Django just because it's large. I'm sure at one point, Django started out as a simple, and clean framework. I am starting to see the same changes in Tornado -- the more people who use it, the more features (and code) are added to keep them satisfied. This goes on until a certain point where the underlying technology (the DB in django's case) changes and it's easier to just start again from scratch.
I commend Waldemar and Thomas for announcing their decision so that someone else can take the reigns, rather that letting things die slowly and quietly.
On the other hand, I can't help but think that "development halted" and "no longer maintained"[1] headlines do the Django community a disservice, as evidenced by comments here[2] asking if Django is dead.
Django is alive, active, and serving many of us very well, thank you. IMHO the reason you don't hear much about it compared to the latest hot shit framework is because it usually "just works", leaving us more time to deal with more important things, like actual business problems.
This is why we stopped using App Engine frameworks at my gig. I'm not sure why, but they tend to die off rather quickly. App Engine Patch, Kay, and Tipfy have all become unmaintained.
My theory is that the critical mass for App Engine frameworks just isn't there. Most people either use the Django that's packaged with the SDK or straight up webapp (or now, webapp2, which is pretty great). Slicing the already small userbase into those willing to use a third-party framework is just too few people to make maintaining it worthwhile.
OTOH, webapp2 was incorporated into the platform. There are a lot of interesting things you can do under app engine and, maybe, platforms as monolithic as Django have a hard time living on Google's platform.
I don't think webapp2 is a framework, though. It was designed to be compatible with webapp2, and then add some niceties, so it's a drop-in replacement for webapp. Even with webapp2_extras, it doesn't contain half of what Django or Rails does.
No, it doesn't. It's very hard to build something as complete - and as self-dependent - as Django on top of something that moves as fast as Google's App Engine.
The only thing I miss when using Django on EC2 is the automagic zero-admin scaling Google provides. The only thing I miss from Django when using App Engine is the admin (which wouldn't work on top of the datastore anyway)
I think this is more like it. We use the Django framework at work and I wish we could get rid of it. These big "do all" frameworks seem like a good idea but by the time you've hacked in all of your needs along with GAE's your begin to wonder why you ever started with.
The main reason is portability. The zero-admin scaling Google provides is very tempting and being able to port your Django app to App Engine can be a good advantage.
Isn't Django on app engine turning more towards Google Cloud SQL? Don't mean to be offensive to anyone but Django-app-engine and Django-nonrel has always seemed to be a bit of a stopgap to me for using Django models and admin with app engine.
further explanation: Since the whole ORM is designed ground up for relational databases, it has always seemed very hackish to me to add the non relational support. IMO better to use the ORM and Admin for what it was intended and just add further upon the stack with pymongo, redis-py etc for those that want to interact with non relational databases.
It's too bad that you're being downvoted by people who only know Django and not Pyramid, Flask, Twisted Web, Nevow, or any other serious Python web framework.
For the record, I didn't vote (and generally don't vote on HN). But maxklein's comment wasn't really constructive and didn't offer any specific criticism. I've said before in replies to his comments that I'd love to hear specific constructive criticism:
I'd much rather see tools like the Django admin evolve interfaces which can be plugged in to the Django ORM or plugged in to some other backend (PyMongo, CouchDB, SimpleDB, AppEngine DataStore or whatever). That feels to me like a more natural point for an abstraction layer than the core ORM itself.