Evgeny_A, Не нужно помещать его в какой-то app, если он используется в нескольких местах. Поместите его на уровень выше и вызывайте напрямую. Судя по всему - он вообще не должен знать про Django. Как я упомянул в ответе - читайте про принципы разделения ответственностей
9550668, self.context['request'].user
Но в сериалайзер нужно отправить context. При использовании self.get_serializer(*args, **kwargs) - request отправляется по умолчанию в self.get_serializer_context()
reqww, OutRef('id') выполняет функцию получения юзера, для которого проводится аннотация, а Subquery позволяет не делать сто запросов вместо одного.
Там просто надо поменять это:
.filter(sender_id=self.request.user.id, receiver_id=OutRef('id'))
на это
.filter(sender__user_id=self.request.user.id, receiver__user_id=OutRef('id'))
Да, я настроил cacheops, но cacheops, как я понял, не заточен под DRF от слова "совсем". Там даже тип request в cache_view проверяется на HttpRequest (тип request дефолтной Django без DRF). Я пытался переписать чать с cache_view под drf, но это действительно очень непростая в поддержке вещь. В итоге - ушел от этого.
Я пытался даже создавать функцию внутри функции (как декоратор) и кешировать изнутри view ее response, но это и выглядит ужасно, и работает так себе. Если одинаковый ответ запроса для всех юзеров наворотить можно, то индивидуальный - крайне трудно.
Пока что ограничился оптимизацией ORM запросов, всякими select_related, perfetch_related, values и связками cache + CacheMiss из cacheops.
Надеюсь в будущем что-то появится. Некоторые небольшие ответы view проще хранить в уже готовом виде. Надеюсь, что cacheops будет развиваться.
Даниил Чернов, разные миграции или разные базы. Сравниваешь миграции. Если одинаковые - идешь в базу, смотришь таблицы, смотришь django_migrations и делаешь выводы, что не так
lukepker, Ежу понятно, а вам не понятно? Искать надо "HTML Forms" и "Django Forms". Изучить клиентскую и серверную части раздельно, а потом объединять. А вообще лучше действительно документацию Django почитать (по ссылке выше от Сергея), а то чую, что не читаная она
Согласен с sim3x. Как его сделали, чтобы легко и быстро собирать приложения, так он там и остался. Его удобно применить для быстро что-то показать (почти любой мануал со встраиванием в веб - на Фласке, ибо можно запустить и оно работает), но дальше он так и не ушел.
JavaUser Spring, забудь про u, просто выбери данные, которые нужны и работай с данными как со словарем (dict). Когда ты используешь json.loads, данные превращаются в обычные python данные. Почитай про списки и словари и вернись к данным после прочтения. Тут кроме них ничего не нужно.
Валентин, речь не о junior фронтах, которые только из коляски вылезли, а о нормальных фронтах, которые вам и за react пояснят, и за angular, и за vue и за все остальное. Почему это тут использовать, как и сколько. Что ставить, как оптимизировать работу. И то же самое касается других стэков. А html + css + один frontend фрэйморк + один backend фрэймворк - это как раз то, что было раньше веб-мастером. Или теперешние full stack
Валентин, может он должен был знать это все потому, что не было деления на front, back и devops? Может быть потому, что раньше веб-разработчик - это "И швец и жнец и на игре дудец"? "А почему сейчас так нельзя?" - спросите вы. Да потому что сейчас столько всего нужно знать, чтобы качественно разрабатывать, что в одну голову это уже не влезет. Уже Agile менеджеры появились, а они до сих пор жалуются, что фронты не умеют lunix использовать...
Nikita Shchypylov, давали бан, написали примерно то, что я написал выше. Предложили предоставить какие-то сертификаты, подтверждающие наличие других навыков. Ничего не предоставлял и спрашивал, какого черта они делают. Через две недели разбанили без объяснения причин. Но в первом письме явно фигурировало, что я послал слишком много заявок, на которые не ответили.
