A
Мы не можем у юзера удалить телефон? Отфильтровать по id юзера (например) и удалить. Нет?
Я не про фильтры говорю. Я говорю про on_delete
Size: a a a
2021 March 06
ИМ
Я не про фильтры говорю. Я говорю про on_delete
Использую каскадное удаление в этом случае
G
Мне нужно, чтоб удалялись телефоны при удалении юзера, но не наоборот
тогда в примере правильно
ИМ
У тебя так и написано
AS
on_delete значит, что Телефон будет удаляться при удалении Юзера или удаляться будет Телефон при удалении Юзера?)
on_delete разрешает тебе выбрать что будет происходить с телефонами когда ты удаляешь юзера
AS
CASCADE удалит все телефоны при удалении юзера
F
on_delete разрешает тебе выбрать что будет происходить с телефонами когда ты удаляешь юзера
Я всё же не понял когда юзать foreign key
AS
Для связи с таблицами
ИМ
CASCADE удалит все телефоны при удалении юзера
Все телефоны юзера*
(
Всем привет, с таким вопросом по архитектуре проекта
Например я делаю сервис email рассылки, и вот в каком файле должен хранится сама функции, которая отправляет поочередно письма ?
Как я понял, в файле views
Например я делаю сервис email рассылки, и вот в каком файле должен хранится сама функции, которая отправляет поочередно письма ?
Как я понял, в файле views
ИМ
Или ты можешь написать отдельный код в отдельном файле, потом импортировать его в вьюшку и вызывать функции к примеру
(
А где лучше этот файл размещать?
Есть ли какие то правила в архитектуре
Есть ли какие то правила в архитектуре
ИМ
По архитектуре в этом плане не подскажу, может деды сейчас ответят
D
( ͡°Ĺ̯ ͡° )
Всем привет, с таким вопросом по архитектуре проекта
Например я делаю сервис email рассылки, и вот в каком файле должен хранится сама функции, которая отправляет поочередно письма ?
Как я понял, в файле views
Например я делаю сервис email рассылки, и вот в каком файле должен хранится сама функции, которая отправляет поочередно письма ?
Как я понял, в файле views
Складывать всю бизнес-логику во view – это очень плохая идея. Стоит выносить в сервисный слой. Вот хорошее видео, как это можно сделать https://youtu.be/HpL6ymFEuu4
(
Складывать всю бизнес-логику во view – это очень плохая идея. Стоит выносить в сервисный слой. Вот хорошее видео, как это можно сделать https://youtu.be/HpL6ymFEuu4
Хорошо, спасибо
DT
ну вообще как правило письма отправляет celery task
соответственно код в файле task/massmail.py
в нем формируется письмо
само письмо отправляется отдельным таском
соответственно код в файле task/massmail.py
в нем формируется письмо
само письмо отправляется отдельным таском
(
ну вообще как правило письма отправляет celery task
соответственно код в файле task/massmail.py
в нем формируется письмо
само письмо отправляется отдельным таском
соответственно код в файле task/massmail.py
в нем формируется письмо
само письмо отправляется отдельным таском
Ну я рассылку писем как пример привел, но спасибо я уверен мне это тоже пригодится.
AF
там есть метод get_queryset
а джанга дорисует новые поля для select_related обьектов?
SI
Nikolay Cherniy
мне кажется лучший вариант все же выучить репортлаб и делать все по красоте, но для быстрого решения я бы выбрал такое)
Если речь об этом https://www.reportlab.com, то скорее всего не походит. Это по большей части платная штуковина, плюс, самое главное, приватные данные пользователей, которые я использую для заполнения табличек, улетают к ним в облако.
DT
а джанга дорисует новые поля для select_related обьектов?
на где ?