Что это за драйвер конкретно?

Поменяй (%d, %s) на (?, ?).

Ну, наверное, потому что ты читать не умеешь. Как говорится, беда по одной не приходит. http://initd.org/psycopg/docs/usage.html#query-parameters «Passing parameters to an SQL statement happens in functions such as cursor.execute() by using %s placeholders in the SQL statement» Даже примеры есть. Литература, парень, литература! Хрен ним, этим программированием. Успеешь, не убежит.

Драйвер

mysql.connector с офф. сайта oracle

Тогда просто %s вне зависимости от типа или %(key)s с диктом.

Да, как и написал anonymous

Привык что в строки можно передавать %d и другие подстановки. Тут оказывается в любом случае %s

Не удивляйся в следующий раз, если встретишь ? (во встроенном sqlite3, например) или :key, это не редкость.

Неужели ещё кто-то пишет без ORM в 2019? А смысл?

Понимание sql при использовании ORM обязательно. Некоторые вещи использую ORM нельзя нормально и понятно сделать.

Таких вещей, где ORM не справится - 2% по моему опыту, и то, во всех ORM адекватных легко ручками порулить кишками и делать RAW запросы, если очень нужно (крайне редко)

Неужели ещё кто-то пишет без ORM в 2019? А смысл?

А ещё они без веб-технологий пишут, вот стыдоба-то какая!

Таких вещей, где ORM не справится - 2% по моему опыту

Таких вещей где ORM нужна в вебе (читай, сложная, глубокая объектная система) ещё меньше. Типичный CRUD очень примитивен. На кой чёрт нужно например набор (массив) который выдаёт SELECT заворачивать в тяжёлые объекты? Всё что нужно, это query builder на котором делается DAL.

Потому, что это удобно, не? И не такие уже они и тяжёлые. Я, в частности, про питон. В нём есть отличные быстрые orm, и уверен (и тестировал), что на простых операциях как раз таки orm - must have. Вот эти вот crud пишутся быстрее с орм

Я тут видел, что чел запрашивал как CGI для питона юзать, и до такого доходило. Лень ему было что-то другое изучать.

Всё что нужно, это query builder на котором делается DAL.

Ну не говори… Как в этих ваших горе-питонов, я не знаю, но в Symfony этот ORM очень и очень даже к месту, если CRUD-ы рисуешь. Обмазал Entity валидаторами и прочими аннотациями и пихай его куда хочешь - в форму, в контроллер, в базу данных, почти без всяких там личных движении. Очень удобно. При всей моей горячей нелюбви к аннотациям, эта гибкость мне оставила огромное впечатление. Тяп-ляп и все есть, работает.

Справедливости ради, более ушлепочной, мислидинговой и еррор-пронной нотации, чем эта, наверное придумать невозможно.

Ну-ну. Миграции тоже ручками прописывать и весь boilerplate. Или какие-нибудь банальные деревья - сравни django_mptt и писать эти запросы ручками.

Обмазал Entity валидаторами и прочими аннотациями и пихай его куда хочешь - в форму, в контроллер, в базу данных, почти без всяких там личных движении

Это просто результат заточенности фреймворка под такой подход. Ничто не мешает достичь того же без ORM.

Миграции тоже ручками прописывать

Как будто без ORM нельзя сделать формальную схему БД. Даже удобнее держать схему отдельно от всего остального.

Вот эти вот crud пишутся быстрее с орм

Опять же, быстрее только потому что фреймворки заточены на это. Есть скаффолдинг и т.п. инструменты, которые подразумевают ORM. Но ни один из таких инструментов, в самом принципе, не нуждается в ORM как таковом. Объяснять же нужность и удобность ORM тем, что «другого в этом фреймворке нет» довольно странно.

И не такие уже они и тяжёлые.

Если объекты не тяжёлые, то очевидно что это просто DTO, которые в динамической скриптоте не нужны. Я понимаю, что именно так ORM в вебе главным образом и используется, и против этого я и возражаю. Потому что, если объекты не выполняют самостоятельно какие-то функции, а применяются только как сущность для переноса данных, то оно того не стоит. В скриптухе есть ассоциативные массивы, которые для этого подходят лучше, менее накладны и в применении намного гибче.

Объяснять же нужность и удобность ORM тем, что «другого в этом фреймворке нет» довольно странно. … это просто DTO, которые в динамической скриптоте не нужны. В скриптухе есть ассоциативные массивы, которые для этого подходят лучше …

Ты - это я, примерно 5 лет назад. :) Попробую угадать - количество «написанного нами» кода в твоих проектах не превышает 10 MB на проект и ты работаешь или один, или в команде безапелиционно самый сильный, под которого все подстраивается, правильно? Если так, тогда моя догадка верна. Так вот, когда начинается работа равным в сильной команде с большим количеством кода, все довольно сильно меняется. Например, ассоциативные массивы становится проклятием, а дата объекты и PHP 7 подсказки типов - очень хорошим, элегантным решением, ORM из «красиво, но как то сложновато», становится стандартом, а прямые SQL запросы в базу - дорогой в ад. И, само собой, никаких полных объектов - экспертов, которые одному позволяет сэкономить кучу кода и контрактов, а только простенькие объекты - компоненты или объекты - диспетчеры (контролеры, например). А все потому, что у разных людей понятие «нормального подхода» сильно отличается, и после несколько попыток все приходит к мысли, что нужны какие-то стандарты, а чтоб этих стандартов было меньше, надо переложить как можно больше логики на сторонние компоненты, а самим писать как можно проще. Так вот, ORM в этом плане один из важнейших сторонних компонентов в попытках достичь простоты и унификации.

А ещё они живут по принципу «Пузо растет, а кончик сохнет».

Попробую угадать - количество «написанного нами» кода в твоих проектах не превышает 10 MB на проект

Не угадал.

прямые SQL запросы в базу - дорогой в ад

Дорогой ад, это когда на ORM пытаются закостылять INSERT ... SELECT ... ON DUPLICATE KEY UPDATE перебирая объекты в цикле и т.п. вещи. Ну а простые запросы на то и простые, что они просты всегда, хоть ORM у тебя, хоть нет. Все те «удобства и простота» выборки и сохранения данных никак с ORM не связаны. Они вполне доступны без всяких ORM.

ассоциативные массивы становится проклятием, а дата объекты и PHP 7 подсказки типов - очень хорошим, элегантным решением

Решением чего? Какой проблемы? Это напротив, только создаёт проблемы когда нужно использовать обобщённые алгоритмы. Т.е. тебе нужно либо писать обёртки, которые принимают нужный тип сущности (класс объекта), либо не указывать тип, а внутри перебирать свойства объекта с помощью рефлексии, по сути работая с объектом, как с массивом свойств. Ну и ради чего было городить весь этот огород? Схему данных, можно держать отдельно, если она нужна. Совсем не обязательно использовать для этого объект. В компилируемых языках (или близких к таковым по скорости) использование языковых средств (классов) для связывания схемы с данными даёт высокую скорость работы. Но мы то про скриптоту говорим, здесь это ничего не даёт кроме ненужного геморроя.

Не угадал.

Странно тогда, как у вас все работает. Не представляю, если честно…

Дорогой ад, это когда на ORM пытаются закостылять INSERT … SELECT … ON DUPLICATE KEY UPDATE перебирая объекты в цикле и т.п. вещи.

Да, так делать плохо. Проще и более универсально расширить Doctrine. Благо, это не сложно.

Это напротив, только создаёт проблемы когда нужно использовать обобщённые алгоритмы.

Для обобщенных алгоритмов - интерфейсы же. :)

Не представляю, если честно

Для этого есть DAL.

интерфейсы же

И какой интерфейс должен быть у validate()? Или serialize()? Видимо mixed.

И какой интерфейс должен быть у validate()? Или serialize()? Видимо mixed.

Не понял вопроса. Поясни, что имеешь в виду? Все зависит от того, что он готов принимать/отдавать. Если он действительно универсален, так и быть, mixed. Но я обычно обхожусь или типом, или nullable типом (необходимое зло, стараюсь избегать, но не любой ценой, конечно), или тип объекта|MockObject (только для моков в тестах). Остальное только в самых крайних случаев, когда по другому просто не получается, например, приходится имплементить доисторический интерфейс с типом параметра mixed.

А сколько вы знаете ORM для aiohttp?

На самом деле намного больше. Проблему N+1 ручками приходится решать с помощью джойнов в той же алхимии. Но джойны это основы на освоение которых потребуется пару дней. Мое мнение как было так и не изменилось: SQL ‒ это язык для домохозяеек, поэтому всегда поражался чсв дебилов с sql.ru.

tortoise orm, gino и peewee-async. Все они лютейший кал. Если требуется асинхронность, то лучше пересесть на Node.js.

Любую могу прикрутить при желании, а что?

Да тут постоянно пишут, что Джанга не нужна, а вот асинхронные решения прям спасли всех на питоне. Видимо, большинство только REST и пишут.

Я только gino юзал и да это не совсем ОРМ. Про ноду спасибо….

Я тоже могу прикрутить. Я говорю не о костылях.

А сколько вы знаете ORM для aiohttp?

Вот не понял. Разве ORM для клиента/сервера?

Я думал, что ORM это для связывания любого кода с БД. А то получается, как у недавнего регистранта «питон программист на убунту», так из здесь «ORM для aiohttp».

Он неправильно выразился, но смысл тем кто в теме понятен. Ему нужна асинхронная ORM. Мог бы и не высказывать свое ценное мнение.

Ну для Rest Api Django излишен. Я пишу только SPA-приложения уже года три. Что не так?