1) Перед кэширование нужно сделать полную выборку из таблицы со связанными данными, точнее только с переводами.
В главный QuerySet должно подгрузиться поле name из таблицы переводов
Делаю так
И это работает, но один из запросов возвращает .
Затем данные кэшируются.
Из кэша я пока не читаю, а только пишу туда.
Если без select_related то потом вообще не пиклится и жестко сваливается…

Пустой результат предположительно из-за Translation.
Там действительно, в отличие от остальных, не все записи имеют переводы.
Но нужно, чтобы несмотря на отсутствие переводов возвращались все записи, и если перевода имени нет то name=default (default='нет перевода'). Но default не из таблицы, а из модели, т.к. в таблице нет нужных записей.

И еще. Если закоментировать только кэширование, т.е. не делать пиклинг, то тот же самый код возвращает не пустой список с переводами.
Такое впечатление, что операция сохранения данных в кэше сессии портит один из QuerySet, который был прочитан до этого.

request.session = объект, содержащий много QuerySet

В чем тут подвох?
Как это сделать?

2) Вот тут http://docs.djangoproject.com/en/dev/ref/models/querysets/#pickling-querysets
про Pickling QuerySets написано, но очень кратко и ничего про select_related в этой связи.
Там пара параграфов и пример в четыре строки.
Я его не понял…
# Assuming ‘s’ is the pickled string.
что такое в данном случае pickled string? да и прочее мутновато.

Растолкуйте пример понятнее.

Вообще-то, если Вы сохраните в сессию запикленные результаты выборки из БД, то это будет равносильно записыванию этих данных обратно в БД… Ведь данные сессии хранятся в таблице сессий.
Не лучше ли вообще обойтись без пикла, а брать запрос?

Lolka
Вообще-то, если Вы сохраните в сессию запикленные результаты выборки из БД, то это будет равносильно записыванию этих данных обратно в БД… Ведь данные сессии хранятся в таблице сессий.
Не лучше ли вообще обойтись без пикла, а брать запрос?

# сохраняем запрос:
request.session["data_query"] = модель.objects.select_related(depth=1).all().query
# на нужной странице восстанавливаем:
data = модель.objects.all()
# и сразу же, пока этот запрос не выполнился -- нам ведь не нужные все данные на самом деле, заменяем его на наш нужный:
data.query = request.session["data_query"]
# ... любые операции с data

Разве запрос .all() не будет выполнен синхронно в той строке где вызван?

Такой вариант тоже полезен в определенных обстоятельствах, как и все другие в своих.
В крайнем случае, я сделаю таблицы в памяти и вообще не буду кэшировать запросы.
Но поставленный вопрос всё равно нужно решить… там явный косяк.

Nick2009
Разве запрос .all() не будет выполнен синхронно в той строке где вызван?

Нет. А вот в Вашем случае – вы форсируете выполнение – list'ом.

Lolka

Nick2009
Разве запрос .all() не будет выполнен синхронно в той строке где вызван?

Нет. А вот в Вашем случае – вы форсируете выполнение – list'ом.

Понятно. Но это очень плохо.