skorpix

Я тоже когда обновлялся до django 1.9, столкнулся с проблемой, что результаты поиска есть, но объект недоступен, отваливался с ошибкой Model could not be found for SearchResult.
Данный случай, как мне кажется, очень похож на мой. Свою проблему я решил так.
Вначале удалил haystack: pip uninstall django-haystack
Затем установил его, используя коммит, который не вошел в ветку 2.4.1
-e git://github.com/django-haystack/django-haystack.git@f1ed18313777005dd77ed724ecbfb27c0b03cad8#egg=haystack

Я, конечно, может и некропостер, но, мне кажется, что это должно делаться следующим образом (вдруг кому этот ответ пригодится):

table_ids = Table.objects.filter(table_field = field).values_list('id', flat=True)
SearchQuerySet().filter(table_field__in = table_ids)

Не проверял на правильность и корректность.

Добавлю от себя про смысл использования.
На одном серваке крутится продакшн и тестовый сервер для проверки изменений. Вначале изменения заливаешь на тестовый, смотришь, проверяешь (думаю, понятно, что изменения могут касаться и установки более свежих версий), если все ок, выкатываешь на продакшн.

Можно так:

@method_decorator(csrf_exempt)
    def dispatch(self, *args, **kwargs):
        return super(<ViewName>, self).dispatch(*args, **kwargs)

andrewshkovskii настройки есть для первого сайта.

BROKER_URL = 'redis://localhost:6379/0'
CELERYD_CONCURRENCY = 8
CELERYD_MAX_TASKS_PER_CHILD = 100
CELERY_EMAIL_TASK_CONFIG = {
    'rate_limit': '6/m'
}

celery запускается через supervisor

[program:celery]
command=/home/%(user)s/.env/bin/python /home/%(user)s/current/manage.py celery worker -l INFO
directory=/home/%(user)s/current
environment=DJANGO_SETTINGS_MODULE="project.settings.%(environment)s"
autostart=true
autorestart=true
redirect_stderr=true
stdout_logfile=/home/%(user)s/log/celery.log

Вобщем, решил проблему. Спасибо за подсказку sim3x .
Все дело было в конфигах nginx, что, в принципе, логично.
В конфиге главного сайта site.ru я поменял default на default_server. В принципе, ничего не поменялось, т.к. раньше была директива default, затем ее заменили на default_server, но поведение то же.
А вот второй конфиг был перепилен почти полностью. Приведу, потом попробую объяснить, какие же ошибки были допущены.

upstream test_project_server {
    server 127.0.0.1:8001 fail_timeout=0;
}

server {
    listen 80;
    client_max_body_size 4G;
    server_name test.site.ru;
    access_log  /home/test_project/log/nginx_access.log;
    keepalive_timeout 5;

    root /var/www/project/public;

    error_page 500 502 503 504 /500.html;
    location = /500.html {
        root /var/www/project;
    }

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        if (!-f $request_filename) {
            proxy_pass http://test_project_server;
            break;
        }
     }
}

Было выпилено две секции сервера. Осталась только одна. Это сделано потому, что в конфигах должен быть только один default_server, а если в одном конфиге два сервера, он не знает к какому обращаться.