django fails, sometimes, very erratic behavior - django

Question

I have terrible problems with django responding differently to the same requests for no apparent reason.
Sometimes i refresh and I see an error, then I refresh and its gone, sometimes the template complains about a missing value then its fine again, again without explanation.
Sometimes it pulls the graphics from the production server, sometimes from the development server.
Worst of all, sometimes, very often, everything looks and loads fine, but a query returns 0 hits even tough a second queryset based on the same query loads fine, how does the same query manages to fail partially inside the same request? For this last one I have the theory that it isn't getting the queryset variable from the view at all.
I am at a loss of keywords for googling about this problem, I'm in the edge of porting the project to php because at least it always renders the same.
The project is installed as a wsgi using apache2, yes everytime i update I make sure to touch wsgi.py, the WSGI script.
Please help.
apache's vhost config:
<VirtualHost *>
ServerAdmin admin#example.com
ServerName example.com
ServerAlias www.example.com
DocumentRoot /home/self/example.com
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /home/self/example.com>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
Alias /media/ /home/self/projects/django/myapp/media/
<Directory /home/self/projects/django/myapp/media/>
Order deny,allow
Allow from all
</Directory>
WSGIScriptAlias / /home/self/projects/django/myapp/wsgi.py
<Directory /home/self/projects/django/myapp/>
Order allow,deny
Allow from all
</Directory>
ErrorLog /home/self/example.com/error.log
LogLevel warn
CustomLog /home/self/example.com/access.log combined
ServerSignature Off
</VirtualHost>
This is wsgi.py
import os
import sys
sys.path.append('/home/self/projects/django')
sys.path.append('/home/self/projects/django/myapp')
os.environ['DJANGO_SETTINGS_MODULE'] = 'myapp.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
And settings.py
#!/usr/bin/python
# -*- coding: utf-8 -*-
# Django settings for myapp project.
import os
PROJECT_DIR = os.path.dirname(os.path.abspath(__file__))
DEBUG = True
TEMPLATE_DEBUG = DEBUG
ADMINS = (
# ('My self', 'self#example.com'),
)
MANAGERS = ADMINS
DATABASE_ENGINE = 'sqlite3' # 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
DATABASE_NAME = os.path.join(PROJECT_DIR, 'myapp.db') # Or path to database file if using sqlite3.
DATABASE_USER = '' # Not used with sqlite3.
DATABASE_PASSWORD = '' # Not used with sqlite3.
DATABASE_HOST = '' # Set to empty string for localhost. Not used with sqlite3.
DATABASE_PORT = '' # Set to empty string for default. Not used with sqlite3.
# Local time zone for this installation. Choices can be found here:
# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
# although not all choices may be available on all operating systems.
# If running in a Windows environment this must be set to the same as your
# system time zone.
TIME_ZONE = 'America/Tegucigalpa'
# Language code for this installation. All choices can be found here:
# http://www.i18nguy.com/unicode/language-identifiers.html
# LANGUAGE_CODE = 'en-us'
LANGUAGE_CODE = 'es-es'
SITE_ID = 1
# If you set this to False, Django will make some optimizations so as not
# to load the internationalization machinery.
USE_I18N = True
# Absolute path to the directory that holds media.
# Example: "/home/media/media.lawrence.com/"
MEDIA_ROOT = ''
# URL that handles the media served from MEDIA_ROOT. Make sure to use a
# trailing slash if there is a path component (optional in other cases).
# Examples: "http://media.lawrence.com", "http://example.com/media/"
MEDIA_URL = ''
# URL prefix for admin media -- CSS, JavaScript and images. Make sure to use a
# trailing slash.
# Examples: "http://foo.com/media/", "/media/".
ADMIN_MEDIA_PREFIX = 'http://media.example.com/media/'
AUTH_PROFILE_MODULE = "myapp.userprofile"
LOGIN_URL = "/login"
# Make this unique, and don't share it with anybody.
SECRET_KEY = '1(!u3tvq^=x)y#kny&^eg&uevo6&y%k-wgl$q$-sl_0+s%3g^5'
# List of callables that know how to import templates from various sources.
TEMPLATE_LOADERS = (
'django.template.loaders.filesystem.load_template_source',
'django.template.loaders.app_directories.load_template_source',
# 'django.template.loaders.eggs.load_template_source',
)
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'pagination.middleware.PaginationMiddleware',
)
ROOT_URLCONF = 'myapp.urls'
TEMPLATE_DIRS = (
os.path.join(PROJECT_DIR, 'templates'),
# Put strings here, like "/home/html/django_templates" or "C:/www/django/templates".
# Always use forward slashes, even on Windows.
# Don't forget to use absolute paths, not relative paths.
)
TEMPLATE_CONTEXT_PROCESSORS = (
"django.core.context_processors.auth",
"django.core.context_processors.debug",
"django.core.context_processors.i18n",
"django.core.context_processors.media",
"django.core.context_processors.request",
)
INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'myapp',
'pagination',
)
UPDATE:
Now I'm positive, the templates work fine and are updated correctly it's the views that behave erratically but withing a pattern, they exhibit old behaviors, sometimes.
This sounds like a caching problem, but I'm not doing any caching on my own, also I always do touch wsgi.py to update the WSGI script which is everything I should need to refresh the application.

Answer 1

Are you storing state in global variables? If so, the response will differ depending on previous requests to the same process.
Rest assured, Django is used reliably by thousands of sites every day. Your problem is not endemic to Django.

Answer 2

Unfortunately it sounds as though you're suffering from a common problem overload. It's hard to figure out exactly what's happening when there's so many things that are wrong.
When it gets complicated, sometimes the best solution is to follow a KISS development method. Write small bits of code, and test them to make sure they work as intended.
If you're worried about WSGI, get a small, simple project running first. Then introduce layers of complexity to try and isolate where the issue begins to occur; providing a great way to resolve the error.
Utilise the python unittest.TestCase module and doctests to help you with the python side of error checking.
All the best! :)

Answer 3

You need to show your views code if you think the issue lies there. Otherwise we can only guess at what the problem might be.