Ну, и сама идея класть соединение в контекст потока как-то дурно пахнет.
Согласен, могут возникнуть проблемы. В частности, когда задачу в фон класть через create_task, то у основного хендлера сессия закроется, а у задачи в create_task он ведь тоже закроется. И будет неявная ошибка. Для этого можно добавить 1 параметр, условно new_session, который отвечает за то чтобы добавить отдельную сессию на функцию, чтобы не зависеть от главной функции. Но да, всё оно имеет свои плюсы и минусы
А точно есть гарантия что совершенно никогда не будет открытия нового конекта в том же контексте? А если потом когда понадобится, забудут же где на самом деле этот коннект хранится и что он не реентерабельный.
Да, гарантия есть. При каждом вызове декоратора идет проверка, есть или нет сессия, если есть, отдается "старая" сессия, если нет, создается новая сессия.
Если я правильно понял ваш вопрос Так в декораторе и так реализовано, если уже есть сессия, то он просто обрабатывает функцию. Если нет, то создает сессию и обрабатывает функцию
Хмм, очень хороший вопрос Если вы имеете в виду допустим шардированный постгре, то возможно сделать ещё один уровень абстракции, над транзакцией наверное.. хотя не особо уверен что поможет, тут надо подумать очень хорошо как это красиво реализовать Если просто допустим ещё редис, то лично в питоне он вообще как глобал переменная используется, и там создается подключение на каждый запрос(да можно объединить запросы). А так для другой СУБД ничего не мешает сделать такой же декоратор Вы задали очень правильный вопрос, пока не готов на него ответить!
Вижу что baidr вам уже ответил по поводу того что переменная изолирована в корутинах. Отвечу по нагрузочному тестированию
Мы с коллегой используем это в работе, проект небольшой, но при 100-1000 рпс проблем нет, вообще никаких. Возможно, это создаст какие-то проблемы при 100000рпс, но до этого пока далеко. Так как по сути мы создаём 1 транзакцию, на 1 хендлер(что важно), и далее в вызываемых функциях мы используем транзакцию хендлера, то не вижу даже предполагаемых проблем, где что может замедлять работу приложения
хмм у меня чуть-чуть другое мнение. Ключевое преимущество, когда много вложенных функций, куда проще работать с базой. Обернул в декоратор, получил сессию. И не надо передавать в функцию никаких объектов, и ничего не надо редактировать(условно понадобился объект сессии в функции, а она у вас 100 раз вызывается, везде редактировать надо будет). Конечно пример это крайний случай, но всё же.
И так же я бы не сказал что это глобальная переменная, в плане логики работы. У вас на каждый стек вызовов функций, свой контекст. То есть соседний вызов этой же функции не получил то значение, которое есть в этой функции
Подскажи конкретнее о каких глобальных переменных речь? Довнесу в статью тогда. Из неявного только импорты хинтов и алхимии, все остальные переменные я попытался вынести в код, чтобы было видно людям.
Про такое впервые вижу, но просто ради интереса можно будет сделать) но пока не в приоритете
Да, циклическая зависимость. Ошибся в выборе термина
да, я ошибся
это делал тестовые файлы и импорты не вернул.
Спасибо!
Только professional версия, там webstorm + datagrip функционал внутри. Так что полная поддержка веб стека + бд
https://www.google.com/amp/s/habr.com/ru/amp/publications/543676/
Сам лично не проверял, но ссылаюсь на статью выше
Однако если бот большой, то можно написать в ТП телеграм и вашему боту сделают больше лимиты. И тогда в лимиты нельзя будет упереться
Согласен, могут возникнуть проблемы. В частности, когда задачу в фон класть через create_task, то у основного хендлера сессия закроется, а у задачи в create_task он ведь тоже закроется. И будет неявная ошибка. Для этого можно добавить 1 параметр, условно new_session, который отвечает за то чтобы добавить отдельную сессию на функцию, чтобы не зависеть от главной функции. Но да, всё оно имеет свои плюсы и минусы
Да, гарантия есть. При каждом вызове декоратора идет проверка, есть или нет сессия, если есть, отдается "старая" сессия, если нет, создается новая сессия.
Если я правильно понял ваш вопрос
Так в декораторе и так реализовано, если уже есть сессия, то он просто обрабатывает функцию. Если нет, то создает сессию и обрабатывает функцию
Хмм, очень хороший вопрос
Если вы имеете в виду допустим шардированный постгре, то возможно сделать ещё один уровень абстракции, над транзакцией наверное.. хотя не особо уверен что поможет, тут надо подумать очень хорошо как это красиво реализовать
Если просто допустим ещё редис, то лично в питоне он вообще как глобал переменная используется, и там создается подключение на каждый запрос(да можно объединить запросы). А так для другой СУБД ничего не мешает сделать такой же декоратор
Вы задали очень правильный вопрос, пока не готов на него ответить!
В этом нет никакого смысла, просто мой коллега так сделал, решил и оставить
Но статья совсем не об этом же)
Вижу что baidr вам уже ответил по поводу того что переменная изолирована в корутинах. Отвечу по нагрузочному тестированию
Мы с коллегой используем это в работе, проект небольшой, но при 100-1000 рпс проблем нет, вообще никаких. Возможно, это создаст какие-то проблемы при 100000рпс, но до этого пока далеко. Так как по сути мы создаём 1 транзакцию, на 1 хендлер(что важно), и далее в вызываемых функциях мы используем транзакцию хендлера, то не вижу даже предполагаемых проблем, где что может замедлять работу приложения
хмм
у меня чуть-чуть другое мнение. Ключевое преимущество, когда много вложенных функций, куда проще работать с базой. Обернул в декоратор, получил сессию. И не надо передавать в функцию никаких объектов, и ничего не надо редактировать(условно понадобился объект сессии в функции, а она у вас 100 раз вызывается, везде редактировать надо будет). Конечно пример это крайний случай, но всё же.
И так же я бы не сказал что это глобальная переменная, в плане логики работы. У вас на каждый стек вызовов функций, свой контекст. То есть соседний вызов этой же функции не получил то значение, которое есть в этой функции
Но это лишь моё мнение)
Подскажи конкретнее о каких глобальных переменных речь? Довнесу в статью тогда. Из неявного только импорты хинтов и алхимии, все остальные переменные я попытался вынести в код, чтобы было видно людям.
Работает, так что можно ставить(ну по крайней мере пока работает)