D
кейс проверяется в миддлваре, поэтому запрос на все методы проходит
Size: a a a
2019 September 17
D
наверное debug=True стоит, у меня такое было
а как дебаг решает этот вопрос?
DT
есть кейс: на первый вход пользователя в django надо отослать приветственное письмо.
сейчас сделано так: смотрим на поле last_login в моделе, если пустое - отправляем
проблема: если одновременно дернуть метод, то запись о последнем входе не успевает записаться в БД и отправится столько писем, сколько раз был дернут метод
сейчас сделано так: смотрим на поле last_login в моделе, если пустое - отправляем
проблема: если одновременно дернуть метод, то запись о последнем входе не успевает записаться в БД и отправится столько писем, сколько раз был дернут метод
а на каком этапе проходит проверка ?
D
в миддлваре...
DT
думаю лучше вынести в логин
DT
на момент авторизации
D
если выносить это в метод логина то last_login мы не отловим
D
он уже будет заполнен
DT
выставление last_login выставляется в сигнале
user_logged_in
может тоже на него подписаться ?
user_logged_in
может тоже на него подписаться ?
D
такая же петруха будет
ОТ
привет всем столкнулся с такой проблемой помогите
localtime() cannot be applied to a naive datetime
localtime() cannot be applied to a naive datetime
DT
и по теории пока ты не авторизируешься не должно выставляться
D
мы веравно не управляем полем для select_for_update
T
last_login нельзя что ли после авторизации заполнить? типа авторизация, отправил сообщение, записал last_login?
D
нет, last_login заполняется авторизационным сигналом автоматически
T
нет, last_login заполняется авторизационным сигналом автоматически
нельзя переопределить такое поведение?)
D
если сами заполним last_Login а ссесии не будет то 500 словишь
T
если сами заполним last_Login а ссесии не будет то 500 словишь
понял
D
нельзя переопределить такое поведение?)
только если login переписать полностью
W
Салют, столкнулся с сложностью в дрф, необходимо реализовать такую структуру {field:”hi”, field1:{}}