Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Correction: running Django tests with MongoDB is NOT slow
At Euro DjangoCon I met lots of people and talked a lot about MongoDB as the backend. I even did a presentation on the subject which led to a lot of people asking me more questions about MongoDB. I did mention to some people that one of the drawbacks of using MongoDB which doesn't have transactions is that you have to create and destroy the collections (like SQL tables) each time for every single test runs. I thought this was slow. It's not Today I've been doing some more profiling and testing and debugging and I can conclude that it's not a problem. Creating the database has a slight delay but it's something you only have to do once and actually it's very fast. Here's how I tear down the collections in between each test: class BaseTest(TestCase): def tearDown(self): for name in self.database.collection_names(): if name not in ('system.indexes',): self.database.drop_collection(name) For example, running test of one of my apps looks like this: $ ./manage.py test myapp ...........lots............. ---------------------------------------------------------------------- Ran 55 tests in 3.024s So, don't fear writing lots of individual unit tests. MongoDB will not slow you down. -
Correction: running Django tests with MongoDB is NOT slow
At Euro DjangoCon I met lots of people and talked a lot about MongoDB as the backend. I even did a presentation on the subject which led to a lot of people asking me more questions about MongoDB. I did mention to some people that one of the drawbacks of using MongoDB which doesn't have transactions is that you have to create and destroy the collections (like SQL tables) each time for every single test runs. I thought this was slow. It's not Today I've been doing some more profiling and testing and debugging and I can conclude that it's not a problem. Creating the database has a slight delay but it's something you only have to do once and actually it's very fast. Here's how I tear down the collections in between each test: class BaseTest(TestCase): def tearDown(self): for name in self.database.collection_names(): if name not in ('system.indexes',): self.database.drop_collection(name) For example, running test of one of my apps looks like this: $ ./manage.py test myapp ...........lots............. ---------------------------------------------------------------------- Ran 55 tests in 3.024s So, don't fear writing lots of individual unit tests. MongoDB will not slow you down. -
Correction: running Django tests with MongoDB is NOT slow
At Euro DjangoCon I met lots of people and talked a lot about MongoDB as the backend. I even did a presentation on the subject which led to a lot of people asking me more questions about MongoDB. I did mention to some people that one of the drawbacks of using MongoDB which doesn't have transactions is that you have to create and destroy the collections (like SQL tables) each time for every single test runs. I thought this was slow. It's not Today I've been doing some more profiling and testing and debugging and I can conclude that it's not a problem. Creating the database has a slight delay but it's something you only have to do once and actually it's very fast. Here's how I tear down the collections in between each test: class BaseTest(TestCase): def tearDown(self): for name in self.database.collection_names(): if name not in ('system.indexes',): self.database.drop_collection(name) For example, running test of one of my apps looks like this: $ ./manage.py test myapp ...........lots............. ---------------------------------------------------------------------- Ran 55 tests in 3.024s So, don't fear writing lots of individual unit tests. MongoDB will not slow you down. -
Correction: running Django tests with MongoDB is NOT slow
At Euro DjangoCon I met lots of people and talked a lot about MongoDB as the backend. I even did a presentation on the subject which led to a lot of people asking me more questions about MongoDB. I did mention to some people that one of the drawbacks of using MongoDB which doesn't have transactions is that you have to create and destroy the collections (like SQL tables) each time for every single test runs. I thought this was slow. It's not Today I've been doing some more profiling and testing and debugging and I can conclude that it's not a problem. Creating the database has a slight delay but it's something you only have to do once and actually it's very fast. Here's how I tear down the collections in between each test: class BaseTest(TestCase): def tearDown(self): for name in self.database.collection_names(): if name not in ('system.indexes',): self.database.drop_collection(name) For example, running test of one of my apps looks like this: $ ./manage.py test myapp ...........lots............. ---------------------------------------------------------------------- Ran 55 tests in 3.024s So, don't fear writing lots of individual unit tests. MongoDB will not slow you down. -
An autop Django template filter
autop is a script that was first written for WordPress by Matt Mullenweg (the WordPress founder). All WordPress blog posts are filtered using wpautop() (unless you install an additional plug-in to disable the filter). The function was also ported to Drupal, and it's enabled by default when entering body text into Drupal nodes. As far as I'm aware, autop has never been ported to a language other than PHP. Until now. In the process of migrating this site from Drupal to Django, I was surprised to discover that not only Django, but also Python in general, lacks any linebreak filtering function (official or otherwise) that's anywhere near as intelligent as autop. The built-in Django linebreaks filter converts all single newlines to <br /> tags, and all double newlines to <p> tags, completely irrespective of HTML block elements such as <code> and <script>. This was a fairly major problem for me, as I was migrating a lot of old content over from Drupal, and that content was all formatted in autop style. Plus, I'm used to writing content in that way, and I'd like to continue writing content in that way, whether I'm in a PHP environment or not. Therefore, I've … -
An autop Django template filter
autop is a script that was first written for WordPress by Matt Mullenweg (the WordPress founder). All WordPress blog posts are filtered using wpautop() (unless you install an additional plug-in to disable the filter). The function was also ported to Drupal, and it's enabled by default when entering body text into Drupal nodes. As far as I'm aware, autop has never been ported to a language other than PHP. Until now. In the process of migrating this site from Drupal to Django, I was surprised to discover that not only Django, but also Python in general, lacks any linebreak filtering function (official or otherwise) that's anywhere near as intelligent as autop. The built-in Django linebreaks filter converts all single newlines to <br /> tags, and all double newlines to <p> tags, completely irrespective of HTML block elements such as <code> and <script>. This was a fairly major problem for me, as I was migrating a lot of old content over from Drupal, and that content was all formatted in autop style. Plus, I'm used to writing content in that way, and I'd like to continue writing content in that way, whether I'm in a PHP environment or not. Therefore, I've … -
Darrera setmana de juny
Aquesta setmana he tocat molt poca cosa de Python i Django, el projecte que ens consumeix gran part del temps és una feina gairebé de rellotgeria però no és un projecte Python. Tot i això he fet servir Django per al prototipat d'algunes part de l'aplicació. És molt més senzill i ràpid muntar un prototip i fer-hi feina que tractar amb l'aplicació real, per molt que tenguem varis entorns de proves. Estic revisant també els vídeos de la Djangocon Europe 2010. He vist el de Django a l'empresa, el dedicat a la testabilitat i el de GUnicorn. Aquest darrer m'ha agradat especialment ja que tenim plans per anar incorporant GUnicorn com a mètode de referència de desplegament d'aplicacions Django. En aquests moments estam fent servir CherryPy i la veritat és que funciona molt bé. Encara que la màxima és "si funciona no ho canviïs" GUnicorn és un sistema WSGI molt més orientat a la feina que CherryPy, amb possibilitat de gestionar connexions síncrones i asíncrones. Els benchmarks que hi posen Gunicorn un poc pitjor que altres sistemses WSGI, però per notar-ne la diferència hem de gestionar un lloc web amb moooltes visites. En aquests casos el que ens puguin dir … -
Separating Django Users
Soon, me and my friends Rob Golding, Ben Jenkinson and Rob Miles will begin with MyUni. MyUni is a response to the terrible systems in place at our university to find lecture information and to submit coursework. We are building MyUni in our favourite framework, Django. We have gone through three prototype iterations thus far [...] -
More django-articles Updates
I've spent a little more time lately adding new features to django-articles. There are two major additions in the latest release (2.0.0-pre2). Article attachments Article statuses That's right folks! You can finally attach files to your articles. This includes attachments to emails that you send, if you have the articles from email feature properly configured. To prove it, I'm going to attach a file to this article (which I'm posting via email). Next, I've decided that it's worth allowing the user to specify different statuses for their articles. One of the neat things about this feature is that if you are a super user, you're logged in, and you save an article with a status that is designated as "non-live", you will still be able to see it on the site. This is a way for users to preview their work before making it live. Out of the box, there are only two statuses: draft and finished. You're free to add more statuses if you feel so inclined (they're in the database, not hardcoded). The article status is still separate from the "is_active" flag when saving an article. Any article that is marked as inactive will not appear on the … -
Deployment Using Fabric
Yesterday just a night before EuroDjangoCon 2010, I was writing deployment scripts for my personal project. I have been using analogous scripts at least for a year for my work projects of different scopes. And I can prove that it's really worth to have such scripts, because they save a lot of time and let you avoid confusion and mistakes. Most of the projects are continuously improved, so the main purpose of deployment in my case is not the initial installation, but handy and fast updating. For each website that I am managing, there are two environments set up under different domains, where one of them is production environment and another one is staging/testing environment. The configuration of staging environment mirrors the production environment. Both have their own webserver configurations, codebases, databases, and uploaded media files. At first the newest features are tested in the staging environment with the copy of live data, and then they are published in the production environment. I am using subversion for version control with third-party modules defined as svn:externals and put under the same codebase. Unfortunately, some of the modules have to be copied if they were originally taken from Git, Bazaar, or other … -
More django-articles Updates
I've spent a little more time lately adding new features to django-articles. There are two major additions in the latest release (2.0.0-pre2). Article attachments Article statuses That's right folks! You can finally attach files to your articles. This includes attachments to emails that you send, if you have the articles from email feature properly configured. To prove it, I'm going to attach a file to this article (which I'm posting via email). Next, I've decided that it's worth allowing the user to specify different statuses for their articles. One of the neat things about this feature is that if you are a super user, you're logged in, and you save an article with a status that is designated as "non-live", you will still be able to see it on the site. This is a way for users to preview their work before making it live. Out of the box, there are only two statuses: draft and finished. You're free to add more statuses if you feel so inclined (they're in the database, not hardcoded). The article status is still separate from the "is_active" flag when saving an article. Any article that is marked as inactive will not appear on the … -
Snippet: Django Columns Filter
I was looking around for an easy way to split lists of items into columns in a way that the number of items in each column would be less than or equal to the number of items in the first column. This prevents a final column with several more items than the others. I came across an old post from Annie Mullin that established a templatetag to do this using a generator. I liked the idea, but felt that a templatetag was too unwieldy - a filter would be simpler and easier to use in a template. So, I turned it into one: @register.filter def columns(lst, cols): """ Break a list into ``n`` lists, typically for use in columns. >>> lst = range(10) >>> for list in columns(lst, 3): ... list [0, 1, 2, 3] [4, 5, 6] [7, 8, 9] """ try: cols = int(cols) lst = list(lst) except (ValueError, TypeError): raise StopIteration() start = 0 for i in xrange(cols): stop = start + len(lst[i::cols]) yield lst[start:stop] start = stop This is then used in a template like this: {% for column in list|columns:"3" %} <ul> {% for item in column %} <li> <a href="{{ item.get_absolute_url }}">{{ item }}</a> … -
Django E-Commerce
Pakt publishing have released a new Django book called Django 1.2 E-Commerce, written by Jess Legg. I'll have a copy soon and post a review here. In the meantime they are offering a free chapter of the book; Chapter 2 Setting up Shop in 30 minutes. -
Django E-Commerce
Pakt publishing have released a new Django book called Django 1.2 E-Commerce, written by Jess Legg. I'll have a copy soon and post a review here. In the meantime they are offering a free chapter of the book; Chapter 2 Setting up Shop in 30 minutes. -
Django E-Commerce
Pakt publishing have released a new Django book called Django 1.2 E-Commerce, written by Jess Legg. I'll have a copy soon and post a review here. In the meantime they are offering a free chapter of the book; Chapter 2 Setting up Shop in 30 minutes. -
"Using MongoDB in your Django app - implications and benefits"
Straight from DjangoCon 2010 here in Berlin. Slides from my talk on "Using MongoDB in your Django app - implications and benefits" are available as a HTML5 web page so you'll need one of those fancy browsers like Chrome to be able to view it. Sorry. -
"Using MongoDB in your Django app - implications and benefits"
Straight from DjangoCon 2010 here in Berlin. Slides from my talk on "Using MongoDB in your Django app - implications and benefits" are available as a HTML5 web page so you'll need one of those fancy browsers like Chrome to be able to view it. Sorry. -
MongoDB backend for Django-nonrel released
Update: It's possible to use simple JOINs via the django-dbindexer now. Finally, Django-nonrel has a MongoDB backend, which was originally started by George Karpenkov and then finished by Alberto Paro, Flavio Percoco, and I adapted the code to the nonrel backend API. This means you can use the Django ORM (from django.db import models) directly with MongoDB. Even better, you can write code that can run on both MongoDB and App Engine (via our App Engine backend) and possibly also SQL. For example, this website is running Django-nonrel on App Engine, but the same code also works with the MongoDB backend and even with Django's SQL backends. So, Django-nonrel allows for writing portable Django apps. This portability will often only be possible between non-relational DBs, but for many simple apps SQL should work, too. You're probably wondering by now: Does the admin interface work? Yes, but it's limited by MongoDB's query capabilities. For example, you can't do JOINs (except for JOINs made possible by django-dbindexer). Installation First, install pymongo, for example via "easy_install pymongo". Then, clone the MongoDB backend (or download the source) and install it by running "python setup.py install". Next, clone the Django-nonrel repository (or download the source) … -
3rd Year Project: Back to Backtrac
After contacting the university regarding my 3rd year project/dissertation, my ideal choice has been confirmed. I'll be making a distributed backup system, based around a Django web interface and AMQP. Backtrac is a pretty old project, and one whose name I am likely to change once I'm working on it. It was started in my [...] -
Making Django and NoSQL Play Nice
Presentation by Nice Alex Gaynor (Berlin, Germany). -
mongoengine vs. django-mongokit
django-mongokit is the project you want to use if you want to connect your Django project to your MongoDB database via the pymongo Python wrapper. An alternative (dare I say competing alternative) is MongoEngine which is bridge between Django and straight to pymongo. The immediate difference you notice is the syntax. django-mongokit looks like MongoKit syntax and MongoEngine looks like Django ORM. They both accomplish pretty much the same thing. So, which one is fastest? First of all, remember this? where I showed how django-mongokit sped past the SQL ORM like a lightning bullet. Well appears MongoEngine is even faster. That's an average of 23% faster for all three operations! -
Django-samaritan, parce que tout le monde a le droit d’aimer Bruce Willis
Le mois de mai est toujours un mois compliqué. Normalement c'est à cause de tout ces jours fériés qui sont autant d'obstacle au travail et qui nous oblige à être tout le temps en retard en mai. Pourtant, cette année, malgré que deux des jours fériés de mai tombent un samedi et que le ... -
Generating aggregate data across generic relations
Edit: I've created a github repo for performing generic aggregation and annotation based on the code from this entry Aggregation support was added to django's ORM in version 1.1, allowing you to generate Sums, Counts, and more without having to write any SQL. According to the docs aggregation is not supported for generic relations. This entry describes how to work around this using the .extra() method. The state of the art To take an example from the docs, it is possible to span relationships when performing aggregations: syntax:pycon >>> Store.objects.annotate(min_price=Min('books__price'), max_price=Max('books__price')) Here we are querying the Store object and annotating the result set with two extra attributes, 'min_price' and 'max_price', which contain the minimum and maximum price of books that are sold at that store. Conversely, if we want to find the minimum and maximum book price over the entire queryset, you would write: syntax:pycon >>> Store.objects.aggregate(min_price=Min('books__price'), max_price=Max('books__price')) The aggregate() method returns a dictionary as opposed to a queryset. This is an incredibly clean API! Suppose you want to aggregate across a GFK This is tricky. A generic foreign key is comprised of two attributes, a ContentType and a foreign key. The models that are GFKed to do not contain … -
Generating aggregate data across generic relations
Edit: I've created a github repo for performing generic aggregation and annotation based on the code from this entry Aggregation support was added to django's ORM in version 1.1, allowing you to generate Sums, Counts, and more without having to write any SQL. According to the docs aggregation is not supported for generic relations. This entry describes how to work around this using the .extra() method. The state of the art To take an example from the docs, it is possible to span relationships when performing aggregations: >>> Store.objects.annotate(min_price=Min('books__price'), max_price=Max('books__price')) Here we are querying the Store object and annotating the result set with two extra attributes, 'min_price' and 'max_price', which contain the minimum and maximum price of books that are sold at that store. Conversely, if we want to find the minimum and maximum book price over the entire queryset, you would write: >>> Store.objects.aggregate(min_price=Min('books__price'), max_price=Max('books__price')) The aggregate() method returns a dictionary as opposed to a queryset. This is an incredibly clean API! Suppose you want to aggregate across a GFK This is tricky. A generic foreign key is comprised of two attributes, a ContentType and a foreign key. The models that are GFKed to do not contain a reverse … -
Generating aggregate data across generic relations
Edit: I've created a github repo for performing generic aggregation and annotation based on the code from this entry Aggregation support was added to django's ORM in version 1.1, allowing you to generate Sums, Counts, and more without having to write any SQL. According to the docs aggregation is not supported for generic relations. This entry describes how to work around this using the .extra() method. The state of the art To take an example from the docs, it is possible to span relationships when performing aggregations: >>> Store.objects.annotate(min_price=Min('books__price'), max_price=Max('books__price')) Here we are querying the Store object and annotating the result set with two extra attributes, 'min_price' and 'max_price', which contain the minimum and maximum price of books that are sold at that store. Conversely, if we want to find the minimum and maximum book price over the entire queryset, you would write: >>> Store.objects.aggregate(min_price=Min('books__price'), max_price=Max('books__price')) The aggregate() method returns a dictionary as opposed to a queryset. This is an incredibly clean API! Suppose you want to aggregate across a GFK This is tricky. A generic foreign key is comprised of two attributes, a ContentType and a foreign key. The models that are GFKed to do not contain a reverse …