IC
вообще несколько питонов на машине боль, мой личный выбор это pipenv - https://github.com/pypa/pipenv потому что создавая окружение я могу указать нужную мне версию интерпритатора из установленных
почему не poerty?
Size: a a a
2020 August 26
IC
пока ничего не понимаю, но идея такая выкинуть django orm для выборки данных и заменить это дело хранимками
Не то чтобы выкинуть orm, но тут появился довольно удобный низкоуровневый wrapper чтобы в питон использовать сырые sql: https://github.com/nackjicholson/aiosql
A
почему не poerty?
я не понял какую проблему для меня poetry решает, после pipenv, сила привычки, если вы сможете привести аргументы за poetry против pipenv, буду только рад
A
ну и pycharm/vscode лучше дружат с pipenv чем с poetry
VF
Кто там про визы фрилансеров спрашивал? Вот по Грузии инфа
https://t.me/nlevshitstelegram/1664
https://t.me/nlevshitstelegram/1664
A
Не то чтобы выкинуть orm, но тут появился довольно удобный низкоуровневый wrapper чтобы в питон использовать сырые sql: https://github.com/nackjicholson/aiosql
сырые sql я могу писать и в django, отчёты такие отчёты, как по мне хранимки это следующий этап эволюции
IC
сырые sql я могу писать и в django, отчёты такие отчёты, как по мне хранимки это следующий этап эволюции
не спорю)
D
если хранимки такие, как были тут в примере от лингвалео, то они не имеют смысла.
хранимки - носитель бизнес логики. перенос бизнес логики из приложения в базу тащит за собой кучу проблем
хранимки - носитель бизнес логики. перенос бизнес логики из приложения в базу тащит за собой кучу проблем
D
есть хороший кейс, когда ты вьюхи заменяешь на хранимки, написаные на чистом sql. это будет работать намного эффективнее, чем селект из вьюхи, с последующей фильтрацией.
кроме того, есть такой инструмент как lateral.
т.е. если ты делаешь храники без бизнес-логики, а только для некого etl-процесса, то скорее всего, это избыточно и ты будешь за это страдать )
кроме того, есть такой инструмент как lateral.
т.е. если ты делаешь храники без бизнес-логики, а только для некого etl-процесса, то скорее всего, это избыточно и ты будешь за это страдать )
Y
есть хороший кейс, когда ты вьюхи заменяешь на хранимки, написаные на чистом sql. это будет работать намного эффективнее, чем селект из вьюхи, с последующей фильтрацией.
кроме того, есть такой инструмент как lateral.
т.е. если ты делаешь храники без бизнес-логики, а только для некого etl-процесса, то скорее всего, это избыточно и ты будешь за это страдать )
кроме того, есть такой инструмент как lateral.
т.е. если ты делаешь храники без бизнес-логики, а только для некого etl-процесса, то скорее всего, это избыточно и ты будешь за это страдать )
когда лень бэкэнд переписывать - иногда так делаем
D
но если ты переносишь в хранимки бизнес-логику полностью или частично, то страдать ты будешь гарантированно )
GL
нагуглил таки пример кода https://habr.com/ru/post/515628/#comment_21973704 это всего 20 строк, он говорит в среднем о 300 строк на хранимку)
GL
нагуглил таки пример кода https://habr.com/ru/post/515628/#comment_21973704 это всего 20 строк, он говорит в среднем о 300 строк на хранимку)
A
как по мне писать на framework - проще, людей найти проще, но когда система устоялась, вот начинается время для оптимизаций
GL
особенно порадовали
COALESCE((SELECT COALESCE(«content_ref».jdesc->>(COALESCE(ljInput->'localeName', '0')), «content_ref».jdesc->>'0')D
особенно порадовали
COALESCE((SELECT COALESCE(«content_ref».jdesc->>(COALESCE(ljInput->'localeName', '0')), «content_ref».jdesc->>'0')ну это цена json-таблиц )
GL
это мы еще не обсуждали тот факт, что SQL устарел и пора бы его чем-нибудь заменить
D
это мы еще не обсуждали тот факт, что SQL устарел и пора бы его чем-нибудь заменить
монгой
GL
мы щас пользуемся БД, в которой можно пользоваться языком гораздо круче (но sql тоже есть)