Django and Memcached: Set Value Not Working

I had a strange memcached bug while using Django. Sometime cache.set(key, value) would save the value. Other times it would not. No warnings or errors. Just not saved.

It turns out the item I was trying to save was near the item size limit of memcached. The default is 1 MB (see the -I flag). Sometimes the item would be less than the max and set would work. Other times it would exceed the limit and set would just stop working.

The man page recommends not exceeding the default. So I solved the problem by saving the item in two parts.

I should also mention that Django file-based cache is pretty easy to use and does not have this limitation. Since all my Django sites run on SSD drives, file-based cache is almost as fast as memcached.



Django Headless Testing: Address already in use Error

Here is a great post for how to run Django tests headless. It uses xvfb.

Sometimes after a test crashes, the next time you run a test, you will get the error:

Traceback (most recent call last):
 File "/home/chuck/.virtualenvs/qdb7/local/lib/python2.7/site-packages/django/test/", line 1189, in setUpClass
 raise cls.server_thread.error
error: [Errno 98] Address already in use

To get rid of this error, find the Xvbf process that was left running after the crash:

ps aux | grep Xv

Then run kill on the pid.

Vagrant, Ansible Error

I am setting up a new Ubuntu system and needed to install Vagrant. Google, gave me this post that shows how to install Vagrant using apt. All seemed good until I ran Vagrant with Ansible and got this error:

ansible provisioner:
* The following settings shouldn't exist: vault_password_file

Luckily, I remembered that vault is a somewhat new function in Ansible. I checked the Vagrant version and it was 1.4.3. That’s pretty old, so I installed the most recent version of Vagrant by following the instructions on the Vagrant site. When I was done, I was at 1.7.2 and the error went away.

PyCharm, Django Dev Server and “password authentication failed for user”

This stuff drives me crazy. I was cruising along, run the Django dev server from the command line. Everything was working well. Then I decided to do some debugging, so I configured the PyCharm Django dev server and got this error:

django.db.utils.OperationalError: FATAL:  password authentication failed

Huh? It was just working. Here’s what was happening. I should mention I was using PostgreSQL. In my local settings file I have:

    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': DB_NAME,
        'USER': 'roi_erp',
        'PASSWORD': os.environ.get('LOCAL_DB_PASSWORD', get_secrets('DB_PASSWORD')),
        'HOST': os.environ.get('POSTGRESQL_HOST', 'localhost'),
        'PORT': '',

First I try to get the DB password from a local environmental variable. If that fails, I look in my project secrets file. My local .pgpass has the LOCAL_DB_PASSWORD, but not the one in secrets. When I ran from the command line, LOCAL_DB_PASSWORD was defined. When I ran from PyCharm, it wasn’t, hence the error message. To solve the problem, I set LOCAL_DB_PASSWORD in PyCharm.

Maybe I should just make the python settings code fail if LOCAL_DB_PASSWORD.

Django Makemigrations Wants to Remove an Existing Field

Django migrations are awesome. But even the docs say you should inspect the proposed migrations before running “migrate”. Recently I ran “makemigrations” and Django wanted to remove a field that was still in my model. What’s going on here?

In this case, the model had lots of fields and added @property methods. It turns out that there was a @property method that had the same name as a model field. I will not go into details about how this happened. Anyway, it turns out that the @property method was an error. Removing it and deleting the migration file fixed the problem.