django: All content tagged as django in NoSQL databases and polyglot persistence
Featuring Jacob Burch, Alex Gaynor, Eric Florenzano, Jacob Kaplan-Moss, Michael Richardson, Noah Silas
You probably know already that Django and NoSQL is hot!
- Unfortunately it looks like the real people on the panel aren’t the same with the ones listed. (↩)
Good lessons on building high availability services from Disqus, the commenting service:
Interesting to note that MongoDB is not mentioned anywhere in the talk, even if Disqus is powered by MongoDB. It is either because MongoDB scaling and high availability weren’t a concern (nb no pun intended, but I doubt that) or that MongoDB is not a central piece of Disqus architecture.
Original title and link: Disqus: Scaling the World’s Largest Django Application (NoSQL databases © myNoSQL)
Tornado, the non-blocking web server and tools open sourced by FriendFeed before their acquisition, seems to get some NoSQL activity. While Django is leading the way in the Python world, judging by the NoSQL projects happening around Node.js, one could say that Tornado, with its non-blocking architecture, may be an interesting alternative.
Thomas Pelletier has ☞ a blog post about a simple websocket + Tornado + Redis Pub/Sub protocol integration:
The principle is very simple: when your user loads the page, she is automatically added to a list of “listeners”. An independent thread is running: it listens for messages from Redis with the subscribe command, and send a message through Websocket to every registered ”listener”. In this example, the user can send a message to herself with a simple AJAX-powered form, which calls a view with a payload (the message), and the view publish it via the publish command of Redis.
This is basically a web chat! If you want to have fun, you can then add a roster, with a presence system, authentication etc…
There’s also a ☞ GitHub project called Trombi:
Trombi is an asynchronous CouchDB client for Tornado.
And I’m pretty sure there are other projects I’ve missed (but you can leave a comment to add them to the list).
Recently, in the Django and NoSQL databases revisited, I’ve covered the coordinated efforts for making Django a NoSQL friendly framework. Alex Gaynor, the main person behind this initiative having the support of the Django community, has ☞ published the final report of the GSOC project:
With this past week GSOC has officially come to it’s close, and I’m here to report on the status of the query-refactor. The original purpose of this branch was to do refactorings to the internals of the ORM, and produce a prototype backend for a non-relational database to demonstrate that this was a viable option. At this time far more work has gone into the latter half of the project, I have developed a fully functioning MongoDB backend, that demonstrates that possibility of using the ORM, almost unmodified on non-relational databases. However, some of the larger refactors that I was originally hoping to do have ultimately not happened, on the other hand they are evidentially not necessary for a functioning backend. At this time there are a number of outstanding tasks, such as: porting the ListField to work on Postgres, and completing the work on embedded documents.
However the largest open question is what of this work should be merged into trunk, and what should live external. My recommendation would be for any changes in Django itself to be merged, including the new form fields, but for the MongoDB backend (and, indeed, any future backends) to live external to Django, until such a time as it obtains a user base anywhere approaching our current backends, as well as a more individuals dedicated to maintaining it.
The guys over ☞ All Buttons Pressed also commented on the outcome of this project:
The biggest design issue (in my opinion) is how to handle AutoField. In the GSoC branch, non-relational model code would always need a manually added NativeAutoField(primary_key=True) because many NoSQL DBs use string-based primary keys. As you can see in Django-nonrel, a NativeAutoField is unnecessary. The normal AutoField already works very well and it has the advantage that you can reuse existing Django apps unmodified and you don’t need a special NativeAutoField definition in your model. Hopefully this issue will get fixed before official NoSQL support is merged into trunk.
Django decided long time ago that Ruby on Rails cannot be the only framework where people can have fun integrating with all NoSQL databases. During this year DjangoCon Europe there were several session dedicated to Django and NoSQL databases:
- Alex Gaynor: What NoSQL support in the Django ORM looks like, and how do we get there
- Peter Bengtsson: Using MongoDB in your app
- Benoît Chesneau: Relax your project with CouchDB
- Tobias Ivarsson: Django and Neo4j: Domain Modeling that Kicks Ass
- Django and NoSQL Panel
What NoSQL support in the Django ORM looks like, and how do we get there
Alex Gaynor speaks about what needs to change in Django ORM to make it more NoSQL friendly:
Reinout van Rees has a summary of the talk ☞ here.
Using MongoDB in your app
Peter Bengtsson talks about his experience of passing from using ZODB for the last 10 years to MongoDB
Some notes from the talk are available ☞ here.
Relax your project with CouchDB
Benoît Chesneau talks about what makes CouchDB appealing to python developers. He also covers the CouchDBkit python framework.
Django and Neo4j: Domain Modeling that Kicks Ass
Not coming from DjangoCon, but still about Django and Neo4j, is Tobias Ivarsson’s presentation: “Django and Neo4j - Domain modeling that kicks ass”:
Derek Stainer summarizes the slide deck ☞ here.
Django and NoSQL Panel
All in all a lot of NoSQL excitement in the Django world! Or should it be the opposite?
Update: Here is the latest Django and NoSQL Databases status update