Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Internet & mobile connectivity
Internet & mobile connectivity The conference and sprint venues will of course be furnished with a suitable wireless network. You'll also be able to get wireless access from your hotel apartments and rooms. You may all the same wish to buy a SIM card for mobile connectivity. You need to do this before you arrive on the island. We recommend Orange, Bouygues or SFR. -
Django sticky queryset filters
In Django, Stuff.objects.filter(a=1).filter(b=1) is almost always the same as Stuff.objects.filter(a=1, b=1). Everyone knows and expects this, and it's very well documented. However, Stuff.objects.filter(rel__a=1).filter(rel__b=1) might not be the same as Stuff.objects.filter(rel__a=1, rel__b=1). This is also very well documented, but in my option this behavior is not always intuitive. Lets take an example: class Tag(models.Model): name = models.CharField(max_length=100) class Entry(models.Model): tags = models.ManyToManyField(Tag) Now if we run Entry.objects.filter(tags__name='stuff') we'd get roughly something like: SELECT `app_entry`.`id` FROM `app_entry` INNER JOIN `app_entry_tags` ON (`app_entry`.`id` = `app_entry_tags`.`entry_id`) INNER JOIN `app_tag` ON (`app_entry_tags`.`tag_id` = `app_tag`.`id`) WHERE `app_tag`.`name` = 'stuff' If we run Entry.objects.filter(tags__name='stuff').filter(tags__name='other') we'd get roughly something like: SELECT `app_entry`.`id` FROM `app_entry` INNER JOIN `app_entry_tags` ON (`app_entry`.`id` = `app_entry_tags`.`entry_id`) INNER JOIN `app_tag` ON (`app_entry_tags`.`tag_id` = `app_tag`.`id`) INNER JOIN `app_entry_tags` T4 ON (`app_entry`.`id` = T4.`entry_id`) INNER JOIN `app_tag` T5 ON (T4.`tag_id` = T5.`id`) WHERE (`app_tag`.`name` = 'stuff' AND T5.`name` = 'other') Two JOIN is exactly what we wanted - a WHERE with a single JOIN wouldn't make sense anyway. A different example* Suppose we want to model books that have multiple authors: class Author(models.Model): nationality = models.CharField(max_length=100) sex = models.CharField(max_length=1) birth = models.DateField(max_length=100) alive = models.BooleanField(default=True) class Book(models.Model): authors = models.ManyToManyField(Author) What if we want to get … -
Django sticky queryset filters
In Django, Stuff.objects.filter(a=1).filter(b=1) is almost always the same as Stuff.objects.filter(a=1, b=1). Everyone knows and expects this, and it's very well documented. However, Stuff.objects.filter(rel__a=1).filter(rel__b=1) might not be the same as Stuff.objects.filter(rel__a=1, rel__b=1). This is also very well documented, but in my option this behavior is not always intuitive. Lets take an example: class Tag(models.Model): name = models.CharField(max_length=100) class Entry(models.Model): tags = models.ManyToManyField(Tag) Now if we run Entry.objects.filter(tags__name='stuff') we'd get roughly something like: SELECT `app_entry`.`id` FROM `app_entry` INNER JOIN `app_entry_tags` ON (`app_entry`.`id` = `app_entry_tags`.`entry_id`) INNER JOIN `app_tag` ON (`app_entry_tags`.`tag_id` = `app_tag`.`id`) WHERE `app_tag`.`name` = 'stuff' If we run Entry.objects.filter(tags__name='stuff').filter(tags__name='other') we'd get roughly something like: SELECT `app_entry`.`id` FROM `app_entry` INNER JOIN `app_entry_tags` ON (`app_entry`.`id` = `app_entry_tags`.`entry_id`) INNER JOIN `app_tag` ON (`app_entry_tags`.`tag_id` = `app_tag`.`id`) INNER JOIN `app_entry_tags` T4 ON (`app_entry`.`id` = T4.`entry_id`) INNER JOIN `app_tag` T5 ON (T4.`tag_id` = T5.`id`) WHERE (`app_tag`.`name` = 'stuff' AND T5.`name` = 'other') Two JOIN is exactly what we wanted - a WHERE with a single JOIN wouldn't make sense anyway. A different example * Suppose we want to model books that have multiple authors: class Author(models.Model): nationality = models.CharField(max_length=100) sex = models.CharField(max_length=1) birth = models.DateField(max_length=100) alive = models.BooleanField(default=True) class Book(models.Model): authors = models.ManyToManyField(Author) What if we want to … -
Django sticky queryset filters
In Django, Stuff.objects.filter(a=1).filter(b=1) is almost always the same as Stuff.objects.filter(a=1, b=1). Everyone knows and expects this, and it's very well documented. However, Stuff.objects.filter(rel__a=1).filter(rel__b=1) might not be the same as Stuff.objects.filter(rel__a=1, rel__b=1). This is also very well documented, but in my option this behavior is not always intuitive. Lets take an example: class Tag(models.Model): name = models.CharField(max_length=100) class Entry(models.Model): tags = models.ManyToManyField(Tag) Now if we run Entry.objects.filter(tags__name='stuff') we'd get roughly something like: SELECT `app_entry`.`id` FROM `app_entry` INNER JOIN `app_entry_tags` ON (`app_entry`.`id` = `app_entry_tags`.`entry_id`) INNER JOIN `app_tag` ON (`app_entry_tags`.`tag_id` = `app_tag`.`id`) WHERE `app_tag`.`name` = 'stuff' If we run Entry.objects.filter(tags__name='stuff').filter(tags__name='other') we'd get roughly something like: SELECT `app_entry`.`id` FROM `app_entry` INNER JOIN `app_entry_tags` ON (`app_entry`.`id` = `app_entry_tags`.`entry_id`) INNER JOIN `app_tag` ON (`app_entry_tags`.`tag_id` = `app_tag`.`id`) INNER JOIN `app_entry_tags` T4 ON (`app_entry`.`id` = T4.`entry_id`) INNER JOIN `app_tag` T5 ON (T4.`tag_id` = T5.`id`) WHERE (`app_tag`.`name` = 'stuff' AND T5.`name` = 'other') Two JOIN is exactly what we wanted - a WHERE with a single JOIN wouldn't make sense anyway. A different example * Suppose we want to model books that have multiple authors: class Author(models.Model): nationality = models.CharField(max_length=100) sex = models.CharField(max_length=1) birth = models.DateField(max_length=100) alive = models.BooleanField(default=True) class Book(models.Model): authors = models.ManyToManyField(Author) What if we want to … -
Custom queries III: MySQL
Ok, we saw how to connect to an SQLite database in Python. Now let's see MySQL. There's only a small difference in syntax, but it's significant. The steps, however, are the same.Import the libraryimport MySQLdb as msNote: The as specifies an alternate name for the library. In this case, I won't have to type MySQLdb again and again. I'll just type ms.Establish a connectionconn = ms.connect (host, username, password, database_name)If you're running this on a machine, normally host is localhost. You'll have to create a root user, which you'll have to see how to do in your particular OS on the Internet. Provide that username and password. Then execute the command create database db_name and use this database as the fourth field.Exhausted? So am I. I know it's a lot of effort, but trust me, the results are totally worth it.Create a cursor as usualcur = conn.cursor ()Remember I said %s doesn't work in SQLite? Well, that's the only thing that works here. Let's write a query.query = "select name from employee where empid = %s" % empidREAD THIS VERY CAREFULLY:Now, empid is an integer, but you still have to pass is as a string. Assume empid is 1234. The … -
Django and IPython Notebook
The IPython Notebook is a really cool application, and I've always wanted to use it during Django development and debugging. The only problem is that it requires a lot of dependencies and I feel no need to encumber my production projects with those dependencies for a feature that I ... -
Supervisor with Django and Gunicorn
Supervisor with Django: A starter guide This post assumes that you have used gunicorn and know what it does. I will try everything inside a virtual environment and hope you do the same. What is supervisor. Supervisor is a monitoring tool that can monitor your processes. It can restart the process if the process dies or gets killed for some reason. Use of supervisor: Why I started using it. In production, I use gunicorn as web server. I started a gunicorn process as a daemon and logged out from the server. My site ran as expected for few days. All of a sudden, we started getting '502 Bad Gateway' and I had no idea why. I had to ssh to the server to find out what went wrong. After ps aux | grep gunicorn, I found out gunicorn wasn't running anymore. My gunicorn process died on its own, and I had no idea when and why. Had I used supervisor, supervisor would have been controlling the gunicorn process. It must have recieved a signal when gunicorn died and it would have created a new gunicorn process in such scenario. And my site would have kept running as expected. Other scenario … -
PyGrunn: Processes, data and (the) rest - Henk Doornbos
(One of the summaries of the one-day 2014 PyGrunn conference in Groningen in the Netherlands). Henk Doornbos gave a talk in 2011 at PyGrunn about large codebases. Nice talk, that one, so I was looking forward to his talk this year. Programming is nice, especially with Python, but in the end the most important thing is to make sure you've handled all the processes and all the data in whatever you've got to build. Designing information systems. How do you do it? Talking to people, reading, brainstorming. It is hard to determine which data you have to work with. A big problem is that data is often stored in databases. Often legacy databases. And databases are much harder to refactor than code! So figuring out the data is very important. Getting the data structure out of written use cases is quite some work. You can look for nouns, for names: those often give important clues. But you'll still miss things. Trying to describe the process also gives clues. Often the process description language/diagram and the data language/diagram don't match. What he's looking for is a reliable, repeatable way to: Precisely describe a business process Find the complete and sufficient set … -
PyGrunn: Geoprocessing with Python - Greg Kowal
(One of the summaries of the one-day 2014 PyGrunn conference in Groningen in the Netherlands). Grek Kowal will talk about geoprocessing with GDAL/OGR. Geoprocessing is a lot about map projections. The earth is round, but not quite. And "round" needs to be mapped on a flat square screen, so you need to to reproject. Lots of ways to do that. What do people do with geoprocessing? Analyzing sensor data, calculating optimal traffic routes, flood risks, etc. Often you have to take multiple data sources and merge them somehow to end up with a proper map. What's there in python? Shapely is nice and pythonic, but it cannot handle many data sources. ArcPy is proprietary. GDAL/OGR is a real swiss army knife: useful like hell, but ugly. QGIS is a graphical swiss knife, very handy for visually toying with your data. GDAL is for rasters (bitmap), OGR for vectors (point, line, polygon). They're now distributed together. (Note: if you manage to install it on OSX you're a king: it is hard...). Why are they so interesting? OGR supports 78 formats from postgresql to the Czech cadastral exchange data format. GDAL in turn supports 133 formates from PNG and JPEG to a … -
PyGrunn: Modern authentication in python web apps - Arthur Barseghyan
(One of the summaries of the one-day 2014 PyGrunn conference in Groningen in the Netherlands). Arthur Barseghyan talks about SSO (single sign on) and two-factor authentication. Single sign on If you have multiple web frameworks and websites, normally every one of them would need a user database and its own authentication system. Without SSO, you could perhaps (bad idea) pick one of them and make that the leading one and hack the rest to support that one. Or you'd expect users to log in multiple times (also a bad idea). Or you could use a custom API to let the sites communicate their authentication data (also a bad idea). With single sign on you don't have many of these problems. As an example, he uses (JaSig) CAS , a java enterprise single sign-on solution. There are a whole lot of plugins. It is open source, scalable and well documented. It supports lots of backends. For logging in you need three parties: a web browser, the CAS server, your application server. Your application server functions as a CAS client. Pro: Centralised authentication for all frameworks and applications. No problem when one app is in Django and the other one in Flask … -
PyGrunn: Documentation is king - Kenneth Reitz
(One of the summaries of the one-day 2014 PyGrunn conference in Groningen in the Netherlands). Note: Kenneth Reitz gave another talk earlier during the day called "growing open source seeds". I was at a different talk, but the title is the same as a talk he gave at last year's EU djangocon. And I do have a summary of that one. A good talk! Note 2: can't get enough? He also compared Django and Flask at the 2013 EU djangocon. Recommended, mainly because of his suggestion to use open source all the things as your software architecture. "It is a helpful mindset to at least treat everything you make like it will be open sourced, even if you won’t actually do it." Anyway, on to his actual talk about documentation! He found a trend in all the stuff he does: the best things are simpler. For instance: prime lenses, handheld games, pen and paper, mechanical watch, a single carry-on bag. Constraints foster creativity. So something that constrains helps you get creative. Kenneth needs simple things to function well. The most well-known Python thing he's build is the requests library. Nice and simple and waaaaay more useful than the default python … -
PyGrunn: SSL, CAs and keeping your stuff safe - Armin Ronacher
(One of the summaries of the one-day 2014 PyGrunn conference in Groningen in the Netherlands). Armin often talks at PyGrunn. I've got three older summaries: the future of wsgi and python 3 (2010), the state of python and the web (2011), and I am doing http wrong (2012). The one I liked most was his 2011 talk at the EU djangocon about the impact of Django. He's proposing a new title for his talk: a capitalistic and system conformant talk about encryption. Well, no, it is just about SSL. He's working at "splash damage/fireteam": infrastructure for games. They want to keep someone from gaming the games, so they encrypt everything. (Note: I like one of their ipad games very much, rad soldiers). It is too easy to forget the bigger picture. He uses an analogy between bitcoin and credit cards. Bitcoins are completely encrypted and whatever. The credit card number, in contrast, is very insecure and unencrypted. But the whole credit card process is very secure. If someone steals your bitcoin key, you lose all the money, but you won't have the same problem with your credit card if it were stolen. So: think about the bigger picture! Regarding encryption: … -
PyGrunn: Writing idiomatic python - Jeff Knupp
(One of the summaries of the one-day 2014 PyGrunn conference in Groningen in the Netherlands). Jeff Knupp wrote an ebook about writing pythonic code. The subtitle of his talk is towards comprehensible and maintainable code. "Idiomatic python" doesn't mean "idiotic snake". It means "pythonic code". Code written in the way the Python community has agreed it should be written. Who decided this? Well, all the python developers through the code they write, share and criticize. The patterns you see there. Who really decides is sometimes the BDFL (Guido) or a PEP. Why would you? Three reasons: Readability. This helps people read your code. You keep the "cognitive burden" low. If I have to think during reading your code, reading your code is harder. I don't want to remember things if it isn't necessary. "Cognitive burden" is the best measure of readability. Obligatory Knuth quote, paraphrased: write code to explain to a human what we want the computer to do, don't write just for the computer. Maintainability. Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Correctness. If you're the only one that can read your code, correctness … -
PyGrunn: gevent - Denis Bilenko
(One of the summaries of the one-day 2014 PyGrunn conference in Groningen in the Netherlands). gevent gives you something that works pretty much like threads without many of the drawbacks. Denis Bilenko is the author of it. It works by using user-level event loops. Gevent mostly works at the level of IO, for instance for web connections, sockets, processes, etc. Gevent tries to be very stdlib compatible. Gevent modules are mostly drop-in replacements for python standard lib ones: just change the import and you use the gevent version. This helps a lot with the learning curve ("just the generic stdlib way of working") and it also helps by forcing backward compatibleness ("it has to work like the stdlib version"). Note: gunicorn, used a lot for Django, uses gevent behind the scenes. Gevent was written to avoid the complexity of event loops. Event loops mean you give up most of the control of your code to whatever is happening inside those loops. Regular python exception handling becomes almost impossible. And you have to give up context managers. And the common synchronous programming style. Giving all this up is not needed: use gevent. Gevent uses "greenlets" behind the scenes: so-called "stackful co-routines". … -
PyGrunn: Sphinx plus Robot framework - Pawel Lewicki
(One of the summaries of the one-day 2014 PyGrunn conference in Groningen in the Netherlands). Pawel Lewicki talks about documention as the result of functional testing. Sphinx is Python's standard way of creating documentation from rst files. The second technology he uses is the Robot framework, including the selenium2 plugin for headless browser testing. Robot framework test files are readable text files. Customers can read it pretty well, the tests contain regular English like "open browser to login page", "input text id_login demo-user", "click button css=.primary-action". Certain words in those text files are "keywords": words with special meaning to a test plugin. "Click button" is one of the selenium2 ones, for instance. There's also a selenium2screenshots plugin with keywords like "add pointy note". And especially "capture": capture a screenshot. This gets placed somewhere in the sphinx doc directory and can be included in the documentation. Screenshots that are always up to date!! He showed some examples. Robot framework code can be included in sphinx, with the proper plugins installed, with a .. code:: robotframework statement, followed by the robot code. A regular .. image:: instruction then includes the screenshot. Adjusting the screenshots regarding viewpoint height and width is possible. For … -
PyGrunn: Advanced continuous integration - Dirk Zittersteyn
(One of the summaries of the one-day 2014 PyGrunn conference in Groningen in the Netherlands). Dirk Zittersteyn introduces us to continuous integration. Always use version control. Even when you're programming on your own. Git, mercurial, subversion. Use branches. Keep the master/trunk branch working always. The master needs to be deliverable at all times. Changes and fixes and new features are made on branches and merged when ready. "Always be integrating". Modified quote from a movie. The mainline should always be "green". All the tests should run at all time. A problem is that agreements aren't always reality. Not everything is tested. You still can get broken code in. Just search github for the string "removed debug statement"... And two branches might be green, but combined they might still bring your mainline down. So... you must check the merge. And, really, you shouldn't merge manually. The mainline shouldn't be merged by mortals, a script should do it. The merge you're trying out should be, again, on a separate branch and only be merged into the mainline when green. Doing this manual isn't good, so they let Jenkins do it. The documentation is on https://github.com/paylogic/paylogic-jenkins-plugins . One of the things they use … -
Using PyCharm with a Django in a Buildout
To introduce a coworker to our project and Django in general, I suggested that he would try PyCharm, a Python IDE. One of the (many) nice things of PyCharm is that you can easily jump to the place where something is declared—ideal for exploring a project. When you use for instance a virtualenv, PyCharm will automatically detect which packages are installed. But PyCharm also supports buildout. As the documentation rightfully claims, PyCharm can automatically detect the use of buildout and enables support for it automatically. However, it defaults to using the path from the bin/buildout script. This usually only adds the setuptools and zc.buildout eggs, so it is of little use. Assuming you are using the djangorecipe buildout recipe, there is also a bin/django script available. And that script includes the paths to all the packages you have specified in your buildout. To do this, go to the settings, search for “buildout” and point PyCharm to the right script. Once you have done that, you can immediately see that code completion works, but CTRL+click also takes you to the declarations inside e.g. the Django package. -
Using PyCharm with Django in a Buildout
To introduce a coworker to our project and Django in general, I suggested that he would try PyCharm, a Python IDE. One of the (many) nice things of PyCharm is that you can easily jump to the place where something is declared—ideal for exploring a project. When you use for instance a virtualenv, PyCharm will automatically detect which packages are installed. But PyCharm also supports buildout. As the documentation rightfully claims, PyCharm can automatically detect the use of buildout and enables support for it automatically. However, it defaults to using the path from the bin/buildout script. This usually only adds the setuptools and zc.buildout eggs, so it is of little use. Assuming you are using the djangorecipe buildout recipe, there is also a bin/django script available. And that script includes the paths to all the packages you have specified in your buildout. To do this, go to the settings, search for “buildout” and point PyCharm to the right script. Once you have done that, you can immediately see that code completion works, but CTRL+click also takes you to the declarations inside e.g. the Django package. -
Using PyCharm with Django in a Buildout
To introduce a coworker to our project and Django in general, I suggested that he would try PyCharm, a Python IDE. One of the (many) nice things of PyCharm is that you can easily jump to the place where something is declared—ideal for exploring a project. When you use for instance a virtualenv, PyCharm will automatically detect which packages are installed. But PyCharm also supports buildout. As the documentation rightfully claims, PyCharm can automatically detect the use of buildout and enables support for it automatically. However, it defaults to using the path from the bin/buildout script. This usually only adds the setuptools and zc.buildout eggs, so it is of little use. Assuming you are using the djangorecipe buildout recipe, there is also a bin/django script available. And that script includes the paths to all the packages you have specified in your buildout. To do this, go to the settings, search for “buildout” and point PyCharm to the right script. Once you have done that, you can immediately see that code completion works, but CTRL+click also takes you to the declarations inside e.g. the Django package. -
Django1.6中自定义用户身份验证功能的教程[附源码]
本教程用于帮大家熟悉如何在Django中自定义用户身份验证功能。通过一个自定义的身份验证类,实现一个最简单的用 […] -
Custom queries II: SQLite
Let's see how to connect to an SQLite database from Python. The current version is SQLite3.Open a Python file, and import the library:import sqlite3Now, open a connection to the database. If the .db file already exists, connection to that file is opened, else a file of that name is created and connection is opened.conn = sqlite3.connect ("/foo/bar/filename.db")For executing queries, we need a cursor. So let's initialize that:cur = conn.cursor ()Now let's write a query.cur.execute ("select something from some_table")You can directly pass the string as a parameter, but for more customisations, you should initialize it separately and pass it as follows:query = "select foo from bar"cur.execute (query)If you want to insert data dynamically into your query, the following is the syntax:THIS DOES NOT WORK:query = "select empid from employee where name = '%s'" % namecur.execute (query)THIS SHOULD BE DONE:query = "select empid from employee where name = ?"data = (name,)cur.execute (query)Note that data has to be a list or tuple. The syntax shown forces a single element to be a tuple. However, if there are multiple elements, just list them out normally like this:query = "select empid, dept from employee where name = ? and salary = ?"data = (name, sal)cur.execute (query)No data … -
Custom queries I: Comparison between SQLite and MySQL
I've already said in earlier posts that you can use SQLite or MySQL as a database for your website. Recently when I was working on one I had to move to MySQL (I'll tell you why later in this article). So I thought I'll tell you guys how to transition.But first, let's compare.SQLite:It is a lightweight DBMSIt is mainly used for testing and for small websites that do not generate too much data.The biggest advantage is that it handles all the data through a .db file which can be transported elsewhere and used in the same wayIt supports up to 2^64 rows (wow!)On the downside, for the kind of data that giants like Facebook and Google generate, SQLite falls laughably shortIt also has low concurrency control, which means that it crashes if too many people are trying to access the same dataThe last point, the concurrency control, was the main reason I decided to switch to MySQL. The database of the website was crashing again and again. Let's look at MySQL now.MySQL:It is tough, inflexible and an extremely powerful DBMSIt is used by Facebook, Google, Twitter, pretty much all the web giants that exist todayIt has very high concurrency controlIt … -
Migrating Django projects with fixtures
When migrating a Django project it's often useful to work with the built-in dumpdata and loaddata management commands. However, this can easily lead to errors like django.db.utils.IntegrityError: Problem installing fixture Could not load foo.Bar(pk=ba): (1062, "Duplicate entry for key 'app_label'"). Such errors indictate that a similar object already exists in the database, and that you can't insert the duplicate from your fixture. There are basically two approaches to dump data in a way that solves this problem: Specify exactly which models to dump Exclude the conflicting models from the dump For the first approach you would use a command like: ./manage.py dumpdata --natural --indent=2 app1 app2 app3 auth.User > dump.json I include the auth data as well in this example, because it's what I usually do. You want to include all third party apps that create their own database tables and store user generated content. You want to avoid apps that auto-populate the database, like thumbnail generators, search indexers, etc. The second approach is to exclude models. You can do this like: ./manage.py dumpdata --natural --indent=2 --exclude=contenttypes --exclude=sessions.Session --exclude=south.Migrationhistory > dump.json If you googled the error django.db.utils.IntegrityError: Problem installing fixture Could not load contenttypes.ContentType(pk=X): (1062, "Duplicate entry for key 'app_label'"). … -
Migrating Django projects with fixtures
When migrating a Django project it's often useful to work with the built-in dumpdata and loaddata management commands. However, this can easily lead to errors like django.db.utils.IntegrityError: Problem installing fixture Could not load foo.Bar(pk=ba): (1062, "Duplicate entry for key 'app_label'"). Such errors indictate that a similar object already exists in the database, and that you can't insert the duplicate from your fixture. There are basically two approaches to dump data in a way that solves this problem: Specify exactly which models to dump Exclude the conflicting models from the dump For the first approach you would use a command like: ./manage.py dumpdata --natural --indent=2 app1 app2 app3 auth.User > dump.json I include the auth data as well in this example, because it's what I usually do. You want to include all third party apps that create their own database tables and store user generated content. You want to avoid apps that auto-populate the database, like thumbnail generators, search indexers, etc. The second approach is to exclude models. You can do this like: ./manage.py dumpdata --natural --indent=2 --exclude=contenttypes --exclude=sessions.Session --exclude=south.Migrationhistory > dump.json If you googled the error django.db.utils.IntegrityError: Problem installing fixture Could not load contenttypes.ContentType(pk=X): (1062, "Duplicate entry for key 'app_label'"). … -
Migrating Django projects with fixtures
When migrating a Django project it's often useful to work with the built-in dumpdata and loaddata management commands. However, this can easily lead to errors like django.db.utils.IntegrityError: Problem installing fixture Could not load foo.Bar(pk=ba): (1062, "Duplicate entry for key 'app_label'"). Such errors indictate that a similar object already exists in the database, and that you can't insert the duplicate from your fixture. There are basically two approaches to dump data in a way that solves this problem: Specify exactly which models to dump Exclude the conflicting models from the dump For the first approach you would use a command like: ./manage.py dumpdata --natural --indent=2 app1 app2 app3 auth.User > dump.json I include the auth data as well in this example, because it's what I usually do. You want to include all third party apps that create their own database tables and store user generated content. You want to avoid apps that auto-populate the database, like thumbnail generators, search indexers, etc. The second approach is to exclude models. You can do this like: ./manage.py dumpdata --natural --indent=2 --exclude=contenttypes --exclude=sessions.Session --exclude=south.Migrationhistory > dump.json If you googled the error django.db.utils.IntegrityError: Problem installing fixture Could not load contenttypes.ContentType(pk=X): (1062, "Duplicate entry for key 'app_label'"). …