@
Одна карточка не может быть в разных группах
Size: a a a
2019 December 29
@
Так же как иметь только одну группу, вы это имели ввиду?
PZ
Т.е. можно как-то глобально в одном месте прописать, чтобы все TextField по умолчанию бы отображались бы как <textarea>?
Т.е. чтобы не прописывать виджек к каждому полю.
Т.е. чтобы не прописывать виджек к каждому полю.
Угу, что-то типа override в доке поищи
MB
Угу, что-то типа override в доке поищи
Да, спасибо!
Тогда выглядит логичным такое правило для текстовых полей:
- Если используется постгрес, то используем только TextField. Если на самом деле надо задать проверку длины строки (хотя в большинстве случаев это не надо), то можно воспользоваться CheckConstraint
Еще линтер flake8-django обратил мое внимание на то, что в мире джанго для текстовых полей считается плохой практикой делать name = TextField(null=True). Т.е. отсутствие значения лучше делать в виде пустой строки. Вначале мне это правило не понравилось. Мол null это как раз и есть хороший индикатор того, что значение еще не было задано. Но сейчас все ж соглашаюсь с тем, что это вообще хорошая идея избегать None, как в БД, так и в коде. Все равно в коде питона мы делаем проверки через Falsy. А наличие None, оно даже для типизации добавляет лишний код, постоянно приходится писать что-то типа error: Optional[str]
Тогда выглядит логичным такое правило для текстовых полей:
- Если используется постгрес, то используем только TextField. Если на самом деле надо задать проверку длины строки (хотя в большинстве случаев это не надо), то можно воспользоваться CheckConstraint
Еще линтер flake8-django обратил мое внимание на то, что в мире джанго для текстовых полей считается плохой практикой делать name = TextField(null=True). Т.е. отсутствие значения лучше делать в виде пустой строки. Вначале мне это правило не понравилось. Мол null это как раз и есть хороший индикатор того, что значение еще не было задано. Но сейчас все ж соглашаюсь с тем, что это вообще хорошая идея избегать None, как в БД, так и в коде. Все равно в коде питона мы делаем проверки через Falsy. А наличие None, оно даже для типизации добавляет лишний код, постоянно приходится писать что-то типа error: Optional[str]
🔐
Крон, celery
вообще, ресурсоёмкие задачи лучше перекладывать на отдельную тачку
🔐
как вариант, на вебхуках врубать
🔐
ну, если уж совсем нет второй машины, тогда ночью врубать пока юзеров нет)
PZ
Да, спасибо!
Тогда выглядит логичным такое правило для текстовых полей:
- Если используется постгрес, то используем только TextField. Если на самом деле надо задать проверку длины строки (хотя в большинстве случаев это не надо), то можно воспользоваться CheckConstraint
Еще линтер flake8-django обратил мое внимание на то, что в мире джанго для текстовых полей считается плохой практикой делать name = TextField(null=True). Т.е. отсутствие значения лучше делать в виде пустой строки. Вначале мне это правило не понравилось. Мол null это как раз и есть хороший индикатор того, что значение еще не было задано. Но сейчас все ж соглашаюсь с тем, что это вообще хорошая идея избегать None, как в БД, так и в коде. Все равно в коде питона мы делаем проверки через Falsy. А наличие None, оно даже для типизации добавляет лишний код, постоянно приходится писать что-то типа error: Optional[str]
Тогда выглядит логичным такое правило для текстовых полей:
- Если используется постгрес, то используем только TextField. Если на самом деле надо задать проверку длины строки (хотя в большинстве случаев это не надо), то можно воспользоваться CheckConstraint
Еще линтер flake8-django обратил мое внимание на то, что в мире джанго для текстовых полей считается плохой практикой делать name = TextField(null=True). Т.е. отсутствие значения лучше делать в виде пустой строки. Вначале мне это правило не понравилось. Мол null это как раз и есть хороший индикатор того, что значение еще не было задано. Но сейчас все ж соглашаюсь с тем, что это вообще хорошая идея избегать None, как в БД, так и в коде. Все равно в коде питона мы делаем проверки через Falsy. А наличие None, оно даже для типизации добавляет лишний код, постоянно приходится писать что-то типа error: Optional[str]
в принципе, пустая строка и None - это разные сущности по смыслу
S
Привет.
Можете просто объяснить для чего нужен параметр related_name?
Часто ли он используется на практике?
Можете просто объяснить для чего нужен параметр related_name?
Часто ли он используется на практике?
tn
Привет.
Можете просто объяснить для чего нужен параметр related_name?
Часто ли он используется на практике?
Можете просто объяснить для чего нужен параметр related_name?
Часто ли он используется на практике?
Часто
tn
Для отношений используется
VT
Привет.
Можете просто объяснить для чего нужен параметр related_name?
Часто ли он используется на практике?
Можете просто объяснить для чего нужен параметр related_name?
Часто ли он используется на практике?
Делаешь два ForeignKey от модели Car к модели Person. Один Person - driver, другой - passager.
При этом в модели Person будет конфликт, так как автогенирируемый related_name - car_set не может быть использован дважды.
Поэтому ты указываешь явно их-
для поля driver - 'driven_cars'.
для поля passager - 'used_cars'
как то так
При этом в модели Person будет конфликт, так как автогенирируемый related_name - car_set не может быть использован дважды.
Поэтому ты указываешь явно их-
для поля driver - 'driven_cars'.
для поля passager - 'used_cars'
как то так
ПБ
а, ну, и раз 500 только при этом флоу - ошибка в контроллере. Можно спокойно на локальной машине пройти этот флоу и отловить ошибку в режиме девсервера. А вообще - крутите логгирование в файлы(хотя бы) и интегрируйте sentry и какой-то алертинг хотя бы на почту при 500
Спасибо! Буду пробовать
SR
а что это за пакет venv?
Лучше пользуйся pipenv
h
Да ,venv надежнее,но для тебя pipenv самое то
SR
Да ,venv надежнее,но для тебя pipenv самое то
Что значит надёжнее?)
h
Pipenv забагован нормально так
h
С 3.8 питоном не дружит
SR
Pipenv забагован нормально так
У тебя старая информация
h
Requirements криво прогружает