Артём Клименко

t = Tiket.objects.filter(user=request.user, sost=True)

это не список(list) объектов, это ленивый QuerySet, который при попытке итерации по оному будет вычислен(и в ряде других случаев), и на каждом шаге будет возвращать экземпляры модели, и этот объект не может быть преобразован в json(стандартными средствами).
Пр этом экземпляры модели, никоим образом сами по себе в json не преобразуются, нет в json никаких моделей, если хотите получить список json объектов, то подавать надо список словарей.

t = Tiket.objects.filter(user=request.user, sost=True).values()
   
    return JsonResponse({'tiketsS': list(t)})

При этом нужно быть уверенным, что все поля которые скармливаем JsonResponse джанга может преобразовать в json (вашу модель должен суметь), только обратите внимание на дату, она у вас станет строкой.

З.Ы. если хотите ответить используйте "комментировать"

для такого простого случая https://docs.djangoproject.com/en/1.8/howto/custom...
просто в самой джанге напишите команду, и запускайте кронтабом, проверенное замечательное средство.
Ставить отдельные решения, в таком простом случае совершенно не требуется, и будет только оверхедом.

Вам нужно вот это https://docs.djangoproject.com/en/1.8/ref/models/i...
У вас есть экземпляр модели(представление в виде объекта питона записи из бд), когда вы делаете update, вы обновляете данные в самой бд, экземпляр модели при этом каким был таким и остался.

появление официальной возможности подключить jinja не значит что расширения стали бесполезны, когда потребовалось в итоге взвесив все за и против всё равно остановился на niwinz.github.io/django-jinja
При этом я не отключал стандартные шаблоны, я использую и то и другое, где узкем местом стали шаблоны, перешел на использование jinja.

пользуюсь примерно таким:

TEMPLATES = [
    {
        'NAME': 'django',
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [],
        'APP_DIRS': False,
        'OPTIONS': {
            'string_if_invalid': 'VARIABLE ERROR',
            'context_processors': [
                "django.contrib.auth.context_processors.auth",
                "django.core.context_processors.request",
                'django.contrib.messages.context_processors.messages',
                'core.context_processors.cities_list',
                'django.core.context_processors.static',
            ],
            'loaders': [
                ('django.template.loaders.cached.Loader', [
                    'django.template.loaders.filesystem.Loader',
                    'django.template.loaders.app_directories.Loader',
                ]),
            ],

        },
    },
    {
        'NAME': 'jinja2',
        'BACKEND': 'django_jinja.backend.Jinja2',
        'DIRS': [],
        'APP_DIRS': True,
        'OPTIONS': {
            'autoescape': False,  # !!!!!!
            "app_dirname": "jinja2",
            "match_extension": ".html",
            "newstyle_gettext": True,
            "translation_engine": "django.utils.translation",
            "extensions": [
                "jinja2.ext.do",
                "jinja2.ext.loopcontrols",
                "jinja2.ext.with_",
                "jinja2.ext.i18n",
                "jinja2.ext.autoescape",
                "django_jinja.builtins.extensions.CsrfExtension",
                "django_jinja.builtins.extensions.CacheExtension",
                "django_jinja.builtins.extensions.TimezoneExtension",
                "django_jinja.builtins.extensions.UrlsExtension",
                "django_jinja.builtins.extensions.StaticFilesExtension",
                "django_jinja.builtins.extensions.DjangoFiltersExtension",
                # "coffin.spaceless" не работает в py3
            ],
        }
    },
]

О, этот просто замечательный запрос, решение для которого есть, но оно не самое явное:
https://docs.djangoproject.com/en/1.8/topics/db/qu... (крайне рекомендую внимательно прочитать)
У меня правда была другая ситуация я спокойно использовал последовательности фильтров, а оно приводило к непонятным выборкам.

в вашем случае должно быть так:

Product.objects.filter(characteristic__characteristic_type__slug='brands').filter(characteristic__characteristic_type__slug='ingridient')

и вот в случае "обратной связи" или связях многие ко многим, эти два отдельных фильтра, не тоже самое что записать всё в одном фильтре!

https://github.com/django-ckeditor/django-ckeditor...

5 Run the collectstatic management command: $ ./manage.py collectstatic. This'll copy static CKEditor require media resources into the directory given by the STATIC_ROOT setting. See Django's documentation on managing static files for more info.

этот пункт точно выполнили?

Вроде простой вопрос, на который тем не менее, крайне сложно дать вразумительный ответ.

Чем больше приложений в проекте, тем лучше?

нет, точно также не является лучшей практикой пихать всё в одно приложение.

Разделение на модули делается для одной простой вещи - борьба со сложностью.
Разрабатывать и поддерживать гораздо проще несколько модулей, каждый со своим функционалом и спецификой, чем один божественный апликйешен.
Самое очевидно разбиение, эт вынесение специфического функционала, напрямую не влияющего на функционирование "ядра", допустим отчёты(если вы не саму систему отчётов пишете), они находятся в отдельном апликешене, я в принципе вообще могу их отключить, и при этом основная функциональность никак не будет затронута.
Затем идёт явное логическое разделение, специфический функционал/задачи, допустим работа с адресным справочником, его периодическая синхронизация и прочее, все специфические задачи работы с ним находятся в отдельным модуле, и как они реализованы не касается остальной системы, при этом сам адресный справочник уже активно используется в остальной системе.
И самый не очевидный этап, это когда один из апликешенов становится слишком сложным, тут можно воспользоваться, как разнесением функционала по отдельным файлам внутри самого апликешена, так и попытаться разнести его по отдельным апликешенам — собственно хорошо спроектированная система где это не придётся делать.

собственно как предложили выше django-eav (или eav-django)
при использовании постгре можно попробовать это: djbook.ru/rel1.8/ref/contrib/postgres/fields.html#...

либо использовать несколько иной подход, каждый ТИП параметра хранить в отдельной табличке.
и связывать объект с параметрами через GenericForeignKey djbook.ru/rel1.8/ref/contrib/contenttypes.html#gen... одно поле внешний ключ на специальную таблицу(описывающую все модели в проекте), второе id в той таблице.

для модальных форм виджет переопределяется по другому:
djbook.ru/rel1.8/topics/forms/modelforms.html#over...

import logging
logging.debug('Этого сообщения не будет')
logging.info('Этого сообщения тоже не будет')
log = logging.getLogger('django')  # описан в настройках
log.debug('этого тоже не будет поскольку у логера "django" level: INFO')   # можно менять
log.info('а это будет')
log = logging.getLogger('имя которого нет в конфигурации джанги')
log.info('тоже не отобразится')
log = logging.getLogger('django.ololo')
log.debug('тоже не отобразится')
log.info('а вот этот отобразится, хоть такой канал не описан в конфиге, но начинается с django.')

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

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

очень мало манов на связку django + ajax

Для джанги и и обычный запрос и ajax, выглядят практически одинаково (нормальные библиотеки добавят в запрос заголовок https://docs.djangoproject.com/en/1.8/ref/request-...), отличия начнутся в том что вам в зависимости от ответа сервера нужно написать поведение на странице, достаточно предусмотреть чтоб сервер вернул вам всё что потребуется для динамического изменения страницы(и происходить оно будет так как вы его напишете, и джанго уже тут не причём)