Donald_Duck, вопрос не в крупности, а в нагрузке. ORM для крупности как раз хорош, большую кодовую базу с ORM легче сопровождать. Но под высокими нагрузками ORM часто становится бутылочным горлышком системы и вопрос удобства разработчика отступает на второй план. Обычно, в этот момент особенно кучерявая часть модельной логики переезжает в хранимые процедуры. С дальнейшим ростом нагрузки проект может полностью избавиться от ORM и перейти на голые SQL-запросы.
AlmazKayum, правильно. Но, честно говоря, не представляю что за бот такой, которому нужен асинхронный вебхук.
Как написано в документации, блокируются get_me и любая функция начинающаяся с send_
Перед двоеточием импортируемый модуль app.py, а после двоеточия переменная app, содержащая wsgi application, которому сервер uWSGI будет передавать запросы.
Почему не просто `module = app` ?
По той же причине, по которой не просто `uwsgi --http :9000 --wsgi-file app.py`
Виталий, смешная часть этого в том, что если проект выстрелил и дорос до того уровня, когда ORM надо подпиливать или вообще от него избавляться, столкновение с MySQL будет существенно более болезненным, чем было бы с PostgreSQL, если бы его выбрали в самом начале.
abroabr, ну, автор вопроса нам кейс не предоставил. Уверен, что у него его и нет в данным момент. А значит обсуждаем сферического коня в вакууме - большинство случаев, средние значения, показатели синтетических тестов :)
abroabr, под сложным запросом я имею ввиду запрос с подзапросами, объединениями и группировками. Ничего экстраординарного, никаких CTE, оконных функции или JSONB.
Само применения ассемблера на современных платформах, без "понимания устройств построения компиляторов", можете попробовать почерпнуть из Jeff Duntemann "Assembly Language Step-by-Step Programming with Linux" и Ray Seyfarth "Introduction to 64-bit Windows Assembly Programming".
Я вас расстрою, но их просто нет. Обычно задачи такого уровня решают люди, способные читать спецификацию CPU и исходники ядра операционной системы, им не нужны учебники.
