AO
хорошим советом было бы не делать связей между моделями из разных аппов
Size: a a a
2019 July 22
AO
это позволяет потом проще переносить апп в отдельный сервис
AO
второй совет - использовать uuid в качестве дополнения к PK или в качестве PK
C
второй совет - использовать uuid в качестве дополнения к PK или в качестве PK
в качестве ид uuid используется. Проблема в том что мне нужны данные из этой модели при работе\показе связянных с ней моделей. Мне нужно кешировать (какая-то прокси модель) в основном сервисе? Не могу же я запрашивать данные из другого сервиса при обращении к какой-то модели основного сервиса?
C
хорошим советом было бы не делать связей между моделями из разных аппов
Жаль что это невозможно в текущейархитектуре уже (
AO
в качестве ид uuid используется. Проблема в том что мне нужны данные из этой модели при работе\показе связянных с ней моделей. Мне нужно кешировать (какая-то прокси модель) в основном сервисе? Не могу же я запрашивать данные из другого сервиса при обращении к какой-то модели основного сервиса?
я часто кидаю эту ссылку https://phalt.github.io/django-api-domains/
AO
тут она как раз подходит
C
спасибо, пойду изучать
AO
какое-то кеширование, ну, да, можно сделать, например, в интерфейсах
M
Привет!
Использую peewee/kivy. Мне нужно добавить в модель поле для кранения mp3 файлов.
В Django я бы слелал это вот так,
Использую peewee/kivy. Мне нужно добавить в модель поле для кранения mp3 файлов.
В Django я бы слелал это вот так,
voice_mp3 = models.FileField(uload_to='upload/mp3. Но никак не могу понять как мне это сделать в peewee. Может знает кто?
2019 July 23
AO
на форуме разработчиков Django 21 июля написали, что Django получит асинхронные вьюшки (кажется, это было последнее согласование перед принятием решения) и началась работа над этими самыми асинхронными вьюшками https://github.com/django/django/compare/master...andrewgodwin:async_views судя по всему, к релизу Django 3.0 (а точнее, к первой альфе, которая выйдет в сентябре) это будет готово...
DT
руками чистил ?
ДА
Откатить миграции не вариант ?
W
Откатить миграции не вариант ?
Вариант
А
на форуме разработчиков Django 21 июля написали, что Django получит асинхронные вьюшки (кажется, это было последнее согласование перед принятием решения) и началась работа над этими самыми асинхронными вьюшками https://github.com/django/django/compare/master...andrewgodwin:async_views судя по всему, к релизу Django 3.0 (а точнее, к первой альфе, которая выйдет в сентябре) это будет готово...
Круто! И не надо будет aiohttp)))
А
на форуме разработчиков Django 21 июля написали, что Django получит асинхронные вьюшки (кажется, это было последнее согласование перед принятием решения) и началась работа над этими самыми асинхронными вьюшками https://github.com/django/django/compare/master...andrewgodwin:async_views судя по всему, к релизу Django 3.0 (а точнее, к первой альфе, которая выйдет в сентябре) это будет готово...
да неужели! круто!
V💊
на форуме разработчиков Django 21 июля написали, что Django получит асинхронные вьюшки (кажется, это было последнее согласование перед принятием решения) и началась работа над этими самыми асинхронными вьюшками https://github.com/django/django/compare/master...andrewgodwin:async_views судя по всему, к релизу Django 3.0 (а точнее, к первой альфе, которая выйдет в сентябре) это будет готово...
Только сейчас начали работу? Оо когда там они уже опубликовали асинхронный роадмап со словами в 3.0 будет первая асинхронщина? Месяца 2 назад? И только сейчас начали что-то делать? Долго..
D
Привет! кто работал с https://github.com/sabricot/django-elasticsearch-dsl отзовитесь пожалуйста.
У меня есть модель Car c полем name и есть m2m с альтернативными именами - alt_names.
Я делаю suggester_match для Car и хочу, чтобы я мог искать как по name, так и по alt_names.
В моделе я создаю пропертю alt_name_indexing, в которой возвращаю все [alt, names], после чего подрубаю уже suggest в документе для поля alt_names.
Есть ли возможность собрать в эластик документе несколько полей, чтобы грузить suggester для документа и по name и по alt_names? Желательно с выставлением весов. Или же мне нужно содать пропертю all_names, засунуть в неё имя, альтернативные имена, черта лысого и уже по этому списку искать?
У меня есть модель Car c полем name и есть m2m с альтернативными именами - alt_names.
Я делаю suggester_match для Car и хочу, чтобы я мог искать как по name, так и по alt_names.
В моделе я создаю пропертю alt_name_indexing, в которой возвращаю все [alt, names], после чего подрубаю уже suggest в документе для поля alt_names.
Есть ли возможность собрать в эластик документе несколько полей, чтобы грузить suggester для документа и по name и по alt_names? Желательно с выставлением весов. Или же мне нужно содать пропертю all_names, засунуть в неё имя, альтернативные имена, черта лысого и уже по этому списку искать?
А
Только сейчас начали работу? Оо когда там они уже опубликовали асинхронный роадмап со словами в 3.0 будет первая асинхронщина? Месяца 2 назад? И только сейчас начали что-то делать? Долго..
вообще, все началось в далёком...:)
https://www.aeracode.org/2018/06/04/django-async-roadmap/
потом вот, с ORM тут поскромнее
https://docs.djangoproject.com/en/dev/releases/3.0/
https://www.aeracode.org/2018/06/04/django-async-roadmap/
потом вот, с ORM тут поскромнее
https://docs.djangoproject.com/en/dev/releases/3.0/
AO
Только сейчас начали работу? Оо когда там они уже опубликовали асинхронный роадмап со словами в 3.0 будет первая асинхронщина? Месяца 2 назад? И только сейчас начали что-то делать? Долго..
первая будет уже точно (и без view)