Поделитесь мнением про оптимизации и подходы, которые вам никогда не пригодились или оказались ложными/вредными

я тебе поставл клоуна потому что

Наш отец учил нас не стесняться своих слабостей. Если у вас горит, ставьте обезъяне клоуна, не стесняйтесь, главное, чтобы вам легче стало.

говновель это скам,

Я не уверен что понял что вы имеете ввиду. Если Laravel то таки да, у него есть определенные болезни роста. Но мы говорим о ORM в общем плане.

Лично я не использую Doctrine, а сижу на illuminate последние лет 6. Он также может работать как db layer в Laravel, но я использую его сугубо со Slim. Обмазываюсь PSR и довольно урчу.

Я не уверен что понял что вы имеете ввиду. Если Laravel то таки да, у него есть определенные болезни роста. Но мы говорим о ORM в общем плане.

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

если бы тебя интересовал мой совет, то я бы посоветовал бежать от говновеля и всего что связано с этой тейлоровской бандой

хотя я вынужден признать, что указывать на такой баг действительно иногда проще как «sql-injection» иначе некоторые просто не понимают о чем речь: «какой квотинг или эскейпинг.. какие плейсхолдеры зачем..»

чушь собачья.

В моей практике был случай когда большой работающий проект переехал с MySQL на Postgres исправлением в двух «сырых» запросах вида

$this->db->select($this->db->raw($query));

где в $query лежала SQL лапша.

Сама база на Postgres создалась автоматически, подхватив миграции написанные на ORM. Достаточно было указать параметры подключения к новой бд.

Для миграций я обычно использую Phinx, он отлично стыкуется с ORM и позволяет делать вот так:

use Phinx\Migration\AbstractMigration;

class InitMigration extends AbstractMigration
{
    public function change()
    {
        $table = $this->table('config_data');
        $table->addColumn('store_id', 'integer', ['limit' => 3])
              ->addColumn('path', 'string', ['limit' => 20])
              ->addColumn('value', 'text')
              ->create();

        if ($this->isMigratingUp()) {
            $table->insert([
                ['id' => 1, 'store_id' => 0, 'path' => 'some/param1', 'value' => '12345'],
                ['id' => 2, 'store_id' => 0, 'path' => 'some/param2', 'value' => '67890']
            ])->save();
        }
    }
}

Phinx сам добавить колонку id с автоинкрементом, created_at, updated_at c timestamp по-умолчанию. При необходимости это поведение можно поменять.

В итоге, структура базы создается в коде, миграциями, а не ручками в клиенте подключения к БД. Что и позволяет добиться нормальной гибкости и переносимости.

Кстати, вы забыли еще одну переносимость - между частями одного проекта и между проектами. То самое переиспользование кода. С ORM оно проще и быстрее, но судя по вашей ненависти к инструменту вы с таким тоже не сталкивались.

если ты не понял

Я понял что вы не осилили ORM и у вас горит. Этого обезъяну вполне достаточно. Я прекрасно помню когда перенос БД был кровавым, но с тех пор уже много воды утекло и ORM инстурменты достаточно развились для того чтобы облегчить эту боль. Если вы все еще кипятите, то мне вас искренне жаль.

Поделитесь мнением про оптимизации и подходы, которые вам никогда не пригодились или оказались ложными/вредными

1. функциональщина. Якобы проблемы императивных языков никогда в жизни не происходят.

2. Минималистичные дистрибутивы, ВМ, suckless софт и топу подобное. Это игры в хакеров, которые никак не увеличивают удобство/продуктивность, зато доставляют геморроя.

3. Тайловые ВМ. По той же причине.

4. DDD. Никто не умеет эти правильно пользоваться.

чушь собачья.

Испытано на практике. Когда к тебе однажды придет менеджер и скажет: «Вася! У меня для тебя отличные новости. Мы подписываем контракт с ООО Вектор! Есть один нюанс, они не хотят покупать Оракл, потому что у них уже куплен MS SQL Server. Я думаю, не будет больших проблем, правда же?». Тогда ему скажи «чушь собачья.»

чушь какая. ORM не защищает от SQL-иньекций.

У вас большие пробелы в знаниях, нормальный ORM фильтрует данные не позволяя попасть иньекции тк там есть валидаторы.

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

Расскажу вам сказку. В моей практике был случай когда ко мне обращались специалисты McAfee представляющие коммерческие услуги по аудиту и защите сайтов от уязвимостей и официально просили разбанить их сканрующие хосты (я человек простой, fail2ban настраиваю сам). Клиент заказывает полную проверку (пентест) каждые 6 месяцев, а тут она споткнулась. После разбанивания они около двух недель искали всякие SQL (и XSS) иньекции на сайте, но так ничего и не нашли. Проект использовал ORM.

Мой текущий проект с ORM под постоянной атакой Китайских товарищей тк находится в ЕС. Пока безуспешно.

Я это все к чему: вы уверены что ваша SQL лапша выдержит такие проверки?

это просто дебилы не способны понять

Вы уже в третьем посте описываете самого себя.

люди которые за этим стоят не имеют ни малейших даже общих представлений

Давайте вы принесете примеры своего безопасного кода без ORM с реальными SQL запросами из реального проекта, не CRUD, а что-то более толковое с join-ами и прочими радостями. А обезъян пока слезет с пальмы и расстегнет штаны чтобы было удобнее обоссывать. Сыграем в эту игру?

если бы тебя интересовал мой совет, то я бы посоветовал бежать от говновеля и всего что связано с этой тейлоровской бандой

Вы так и не поняли что я не использую Laravel. Я использую инструменты которые могут в том числе в него встраиваться, не более того. Вместо Laravel я использую Slim.

хотя я вынужден признать, что указывать на такой баг действительно иногда проще как «sql-injection» иначе некоторые просто не понимают о чем речь: «какой квотинг или эскейпинг.. какие плейсхолдеры зачем..»

Вы таки перечитали мое сообщение второй раз и поняли о чем я. Так держать!

Я понял что вы не осилили ORM и у вас горит.

мы на сильно разных уровнях знаний и опыта в данном вопросе. тот уровень на котором ты находишься - я его перешел полтора десятка лет назад как минимум.

Doctrine2 я использовал еще 15 лет назад и хорошо в ней разбирался и в ее DQL и кешах, энтити-менеджерах, проксях и проч. до этого использовал ZendDB, до этого с 2003 писал SQL. что касается говновеля, в последние 6 лет у меня были проекты где я работал с ним и с его элокентом и мигратором и всем-всем-всем смердящим скам-говном что в нем есть.

Я прекрасно помню когда перенос БД был кровавым, но с тех пор уже много воды утекло и ORM инстурменты достаточно развились

да просто ты не разрабатывал никакой хоть сколько нибудь осмысленный проект использующий СУБД. и тем более не переносил проект сложнее хеловорда селект * жойн с одной СУБД на другую. да и знания об sql бд у тебя околонулевые примерно как у авторов laravel (хотя нет, у них всё же меньше знаний)

по существу: конечно такой проектик который удастся так перенести может существовать. примерно полтора десятка лет назад я лично переносил пару таких мною же разработанных проектиков под доктрин2. а еще раньше - в конце нулевых, переносил проекты на зенде.

я повторю свой тезис: если у тебя селект жойн - это весь sql, то никакой помощи тебе при миграции orm не оказывает - такое портирование вручную не требует понимания смысла и делается механически без рисках семантически искажений, а за пределами этого orm ничего и не умеет.

при хоть сколько-нибудь полезном использовании СУБД - задачи переноса совершенно иные. и там тем более ORM никак в приницпе помочь не может, потому как он никак в этом не участвует.

но тебе об этом конечно не известно, потому что ни про SQL ни про SQL-БД ты толком-то ничего не знаешь. да и опыта у тебя нет.

я пока пойду на обед

мы на сильно разных уровнях знаний и опыта в данном вопросе. тот уровень на котором ты находишься - я его перешел полтора десятка лет назад как минимум.

Вы застыли в развитии. Жду ваш код чтобы обоссать. Иначе придется обоссать вас.

конечно такой проектик

Annual revenue is currently $36M per year with $150M turnover. Это за прошлый год. Знаю, немного, но кризис в еврозоне, то се, покупательную способность пожрал долгоносик и тд. В позапрошлом было больше, но тогда вышли на рынки Канады и Японии что сыграло в плюс.

Вы правы в том что мы с вами на разных уровнях и в разных лигах, вот только путаете расположение этих уровней. Можно иметь 20+ лет опыта разработки и работать удаленно в международных компаниях на действительно большими проектами, а можно с 20+ годами опыта сидеть на зп и ненавидеть ORM. Мы не одинаковые.

еще раз, вот в целом по уровню твоих рассуждений, оценок, ты на том уровне знаний, который я преодолел полтора если не больше десятка лет назад. теперь про migrate

В итоге, структура базы создается в коде, миграциями, а не ручками в клиенте подключения к БД.

но судя по вашей ненависти к инструменту вы с таким тоже не сталкивались

про мигратора - я не просто его знаю, и много использовал, я его очень неслабо расширял и менял. и всякие фигнюшки добавлял и поддержку новых типов добавлял в этот его билдер сраный и расширял schema grammar, и постресовую грамматику доводил до ума. и миллиард веще касаемо адаптации типов, более того, я решил там ряд совершенно диких говноошибок говнодизайна и с подключениями и с накатом схемы и с очистителем. я делал это для проектов на пятерке, на девятке, я переносил туда-обратно эти решения. я интегрировал это всё в их весьма сложную собственную систему проходящую через весь фреймворк, я увзывавал это всё с доводками до ума артизановских миграторных команд. я конечно же читал исходники этого говна и конечно же я всё это да и поведение самого говновеля местами покрыл тестами. и это только то, что касается миграций (не буду перечислять про остальной фреймворк, что я делал для элокент и пр). поэтому не надо мне ля-ля, понимаешь?

сказать я об этом смердящем токсичном говенль кале в частности конкретно говномигратора могу следующее:

1. он не несет никакой value. вообще. он не нужен

2. представляет собой просто свалку игрушечных какашек некоторых из которых прям настоящие какашки. набор ущербных, ошибочных «идей»

3. как и весь говновель - он вреден. он активно вреден. токсичен. для разработчика, для бизнеса, для всего

4. это инструмент написан СЧВ мудаками не имеющими ни элементарных знаний, ни опыта, ни способности думать, ни понимать чужие идеи ни реализовать хоть что-то осмысленное. короче, инструмент написан дурачками

5. «оф кос»… как грамотному разработчику способному думать, что-то понимающему, мне было сразу понятно (с первых трех минут знакомства с этим хламом), что это не мейкает ничего «а бриз», а являет собой игрушечное, но очень очень токсичное говно. почему мне на этой реке токсичного говна пришлось строить новые проекты - другой вопрос. я не могу представить себе грамотного программиста который после пары минут не будет этого понимать относительно говновель.

это было о ларавельном миграторе

вы с таким тоже не сталкивались

создается в коде, миграциями, а не ручками в клиенте подключения к БД

теперь обо мне (или это больше о тебе).

чтобы делать миграции, ни говновель и его сраные пердушки в миграторе не нужны. для этого нужно только знать DDL базы данных. никакая говноабсракция ни говновельская ни ликвидбезовская ни еще какая-то там пердушка не нужы - это ошибочная идея, понимаешь, ошибочная, это глупость от дурачков

чтобы такие миграции накатывать говновель тоже не нужен.

есть другие инструменты, да вообще - самопальный мигратор делается за день. свой первый примитивный мигратор я сделал лет 20 назад (я правда не знал, что это мигратор)

я понимаю конечно что до идеи миграций конкретно ты дошел только когда дурачок горе-недопрограммист тейлор тебе показал, но ты не обощай на других

еще раз,

Еще раз, код или обоссаны. Хватит языком трепать.

Похоже что вы из тех программистов которые застыли в своем развитии и забронзовели. Попытки обзывать всех вокруг дебилами в ответ на справедливую критику застарелых суждений выдают то что вы привыкли общаться с джунами и таким образом самоутверждаться. Живительная струя обезъянней урины приведет вас в чувство.

Либо вы приносите свой код и мы его обоссываем. Либо мы обоссываем вас закрепляя на форуме за вами статус балабола. Выбор за вами.

Давайте вы принесете примеры своего безопасного кода без ORM с реальными SQL запросами

я честно говоря удивлен… мы сильно на разных уровнях это точно… ты действительно не знаешь как вызвать функцию quote от драйвера БД? или не знаешь как поставить плейсхолдер в запросе? надо же быть таким дном, пфф

да тебе нечем как выяснилось

Код запроса без ORM не смогли показать, который был бы устойчив к SQL-injection. А аппеляция к авторитету - провалилась, не один вы использовали Zend и Doctrine в бородатые года.

Я дал вам шанс несколько раз, вы даже не попытались воспользоваться. Слова ничего не стоят, важен код. Если у вас тут был какой-то атворитет, то вы его успешно слили, впрочем, ничего нового.

Подытоживая. Вы, батенька, балабол. После такого тут самазабаниваются обычно. У ваших слов нет веса, а вы сам - забронзовевший луддит. Обсыхайте.

Тратить на вас время дольше смысла не вижу, по началу казались вкусной едой, но сейчас уже плохо пахните.

ты даже минимально не имеешь компетенций чтобы рассуждать о таких вопросах

Код запроса без ORM не смогли показать, который был бы устойчив к SQL-injection

слушай, ты реально дурачок оказывается

Если запретить генерацию SQL на клиенте, то любой запрос будет безопасным.SELECT x, y FROM foo WHERE x = ? с привязкой на стороне базы. И всё, больше ничего в пхпшные лапы не давать.

Тем не менее, когда я работал в Цифре, именно описаный мной случай миграции проекта с Оракла на MS SQL Server имел место быть, и спасло проект только то, что большая часть запросов была реализована на ОРМ. Ну иди и расскажи Вексельбергу, какой ты умный и какой он дебил, и только ты один знаешь как надо работать. Но что-то мне подсказывает, что очередной админ детского садика решил научить миллиардный бизнес, как надо деньги зарабатывать.

Ахтунг, аттенсион, увага! Обезьяныч, вы имеете дело не с каким-то собачьим хреном, а с ПХП ФРИЛАНСЕРОМ!

На какой российской фриланс-площадке можно разместить заказ?

Вы говорите о prepared statemnts которые в PDO являются emulated, а не real.

Prepared statements не защищают от атаки с использованием multibyte, классический пример

$pdo->query('SET NAMES gbk');

$var = "\xbf\x27 OR 1=1 /*";
$query = 'SELECT * FROM test WHERE name = ? LIMIT 1';
$stmt = $pdo->prepare($query);
$stmt->execute(array($var));

Есть много вариантов, он специфичны от версии к версии БД, те prepared statements далеко не от всего спасает. Потому (в том числе) и были придуманы валидаторы в ORM.

Ахтунг, аттенсион, увага! Обезьяныч, вы имеете дело не с каким-то собачьим хреном, а с ПХП ФРИЛАНСЕРОМ!

Вообще ничего не имею против фрилансеров. И тем более против PHP-фрилансеров. Сам лет 15 назад проходил это еще на oDesk.

хотел разместить заказ анонимно, но в их интерфейсе нигде нет указаний кому будут видны ФИО. поля для ввода есть, но нет информации о том, это для подтверждения личности (чтобы потом сверить с паспортом), или для публичного профиля. в головах проектировавших такие сложные концепты видимо не укладываются

Похоже что он пытался АНОНИМНО разместить заказ на фриланс бирже. Видимо забронзовевшему гуру дали задачу с которой он не справился (Laravel+ORM) вот он и решил ее сделать по-тихому чужими руками.

была реализована на ОРМ. Ну иди и расскажи Вексельбергу

1. представь у тебя есть код, там несколько запросов, допустим ты их переписал (запросов, а не select * ляля join от orm). ок. семантически они тоже самое. но в исходном коде транзакция на уровне RR, исходная БД - версионник, с сопутствующими элементами выполнения такого запроса,
   целевая допустим полуверсионник. нужно выяснить про целевую БД в части RR, нужно выяснить чувствителен ли это весь код к read-skew например хотя бы. и как мы это исключим. как вообще тебе может помочь наличие ORM тут?

2. другой пример. положим в исходном коде транзакция на уровне S, но в целевой бд (Oracle) реального S - нет. код финансово значимый. Какую часть твоей работы сделает ORM?

3. куда более простой пример. допустим ты перенес некоторый запрос, но в оконном вызове целевая БД ругается что нет во фрейминге детерминированного порядка, но для данной функции SQL-стандарт это разрешает. целевая бд не совсем дура - допустим оракл. нужно понять корректен ли исходный запрос который ты же написал 3 года назад (и та БД тебе это разрешила). нужно вспомнить смысл этого кода в предметной области. нужно понять, почему оракл предпочел здесь нарушение стандарта в части вызова этой оконной функции. приять решение. залепить чтобы заработало причем заработало правильно. 4) то же что и 3 но в исходном запросе в оконном вызове задан фрейм, целевая БД говорит это невозможно. стандарт действительно это запрещает. ничего сложного, простейшие вещи, но нельзя внести семантической разницы. но какую часть твоей работы тебе сделает ORM тут, клоун?

это я про самоочевидные вещи (таких можно привести в том числе и совсем примитивных), то что на поверхности.

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

prepared statemnts которые в PDO являются emulated, а не real.

там и те другие, клоун

Вы говорите о prepared statemnts которые в PDO являются emulated, а не real.

Проблемы индейцев.

Я с вами закочнил, обтекайте. Ставьте мне клоунов молча, не отвлекайтесь, а то еще в рот натечет.

Но вы бы хоть ради приличия загуглили и выяснили что все сводится к С-обертке mysql_real_escape_string(), а при переключении в режима в $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); по-настоящему готовится только то что позволяет конкретная версия БД, а что не позволяет - молча идет fallback к emulated. Обычно в каждой версии есть свой список SQL Syntax Permitted in Prepared Statements и все остальное Other statements are not supported.

Видимо забронзовевшему гуру

у забронзовевшего гуру там трагедия - его кинули на, страшно сказать, 150 баксов! Масштаб работ, конечно, потрясает воображение!

Есть много вариантов, он специфичны от версии к версии БД, те prepared statements далеко не от всего спасает. Потому (в том числе) и были придуманы валидаторы в ORM.

Хорошо, возьмем от орма только валидатор, и будем им проверять данные для prepared statements. Теперь безопасность железобетонная, сам орм не нужен! Инъекции это страшилки для пхпшников, привыкших подставлять переменные в строку. Понятно, что ORM придумали не для защиты от инъекций, но реклама напирает на это качество, иначе трудно продать эту технологию пхпшникам. И правда ведь неочевидно зачем такие приборы.

представь у тебя есть код

мне не надо представлять, что у меня есть код. Потому что у меня прям сейчас перед глазами есть код. Этот код в продакшене работает на MySQL, а для юнит-тестов используется H2. Что там юзается для интеграционных не ведаю, пусть SDETы парятся. Волшебство, правда? А, стой, нет не волшебство, это называется гибкая масштабируемая архитектура.

Хорошо, возьмем от орма только валидатор

Конечно, валидатор можно и без ORM сделать, не вопрос. Вот только как с переносимостью быть? Тоже самим реализовывать? А с миграциями (изменение структуры бд)?

ORM это удобный инструмент который предлагает удобно реализовать три основные вещи: миграции, безопасность и переносимость.

Давайте еще раз, проговорим - можно отдельно сделать безопасность как вы описали. Что будете делать с миграциями и переносимостью?

Я понимаю что ORM на вкус и цвет разные, как фломастеры. Но удивлен таким хейтом к ним, как будто первое знакомство с ORM прошло без смазки.

ты хоть понимаешь как глубоко ты обосрался-то?

готовится только то что позволяет конкретная версия БД

ты безграмотный и тупой. PDO умеет отправлять и эмулируемые и настоящие. в твоем любимом ларавеле для быдла по-дефолту настоящие (тебе фанату должно быть стыдно этого не знать), и предписан только такой режим работы (баг с emulated говновель не примут), но к безопасности это отношения не имеет, хотя ни дебилам ларавеля, ни уж тем более тебе, клоуну, конечно этого не понять.

мне не надо представлять, что у меня есть код. в продакшене работает на MySQL, а для юнит-тестов используется H2

на практике так можно тестировать только бложик с двумя табличками.

но это твой предел в общем-то, никаких проектов тем более где осмысленно используются субд ты не разрабатывал. оттого и нулевые знания о разработке и субд. а те примеры что я описал - из моей практики

Миграции на коленке написать. Переносимость не нужна. А если очень хочется, то нанять спеца, который тупо перепишет запросы. Если они не размазаны по всему коду, а изолированы в отдельном слое, то это технически несложная задача. Но заранее беспокоиться о переносимости это порок подобный преждевременной оптимизации. А вдруг никогда не понадобится? А мы в это вложимся. Нет, имхо единственная реальная причина популярности ORM это нежелание связываться с SQL, чтобы оно как-то само запросы написало для малограмотного кодера. Т.е. это мечта об ИИ на самом деле. Но ИИ получился недоделанный, поэтому на деле приходится разбираться и с SQL, и с особенностями реализаций ORM. Так что как всегда борьба со сложностью увеличивает сложность.

Свинья! Ты зачем кусаешь обоссаное обезьяной?

на практике так можно тестировать только бложик с двумя табличками.

вероятно, господин фрилансер не знает, что значит юнит-тестирование.

Переносимость не нужна

Мы вам перезвоним.

технически несложная задача.

Прям поспорил бы. Но вполне может быть, что лично для вас - оно не сложное.

Я точно зубы обломал об переписывание процедур Sybase на функции PostgreSQL. Вложенные транзакции средствами ТОЛЬКО ванильного PostgreSQL просто в принципе нельзя сделать 1в1, сохранив и логику их откатов, и формат ответа.

В позапрошлой жизни (до погружения в БД-мир) облом такого же масштаба был с конвертацией SVG-шного clipPath в DXF. Тоже 1в1 нереализуемо вообще никак, ни при каких обстоятельствах. Только очень грубые костыли подставляемые, что называется «по месту», по претензиям заказчика.

Хорошо, возьмем от орма только валидатор, и будем им проверять данные для prepared statements.

Нет, это чушь.

Логика работы с БД такова, что средства формирования литералов (квотирования/эскейпинга строк) принимаются как корректные. Если вы не можете принимать их за корректные, тогда возникает вопрос за счет чего вы принимаете корректным всё остальное: СУБД, интерпретатор и т.д.

Этих функций quote, quoteIdent и основанных на них prepared statements (замен плейсхолдера) в «драйвере» должно быть достаточно, чтобы встроить строку параметром.

Драйверы psycopg, линейки pdo, линейки jdbc и десятки других драйверов доступа к БД успешно квотируют и подставляют строки, миллионы программ это используют и там нет багов.

Идея о том, что в «драйвере» нет средств для отправки запроса в БД без багов, а потом нужно использовать ORM - это ложный тезис. Это означало бы с psycopg нельзя безопасно встроить параметр-строку без привлечения alchemy. Это абсурд, так утверждать может только крайне некомпетентный программист. Нет ORM не «защищает», защищает функция quote/quoteIdentifier «драйвера доступа к БД».

Бывают ли баги в quote (или escape) в драйверах БД? Такие случаи исторически были в php. Вообще если говорить о php-pdo, то он в принципе представляет собой кривое убогое поделие по многим факторам. Значит ли это для «защиты» нужно использовать ORM - конечно нет. Эти баги фиксят когда находят, это считается urgency.

клоун, я тестирую больше и дольше чем ты вообще отношение к разработке имеешь. в нынешнем проекте у меня >3500 одних только интеграционных тестов и все они - каждый работают на той же самой версии СУБД как локально так и на ci/cd.

более того, я построил механизм приводящий бд к нужному тестовому состоянию, с подготовкой перед каждым тестом. и вся эта автоматика доступна как из unit-тестов так из интеграционных (хотя сейчас такие уже появились готовые я видел). кроме прочего мной разработаны подходы и решения для повторного использования кода в этих состояниях в том числе разрешением зависимостей и визуальзации. и я научился этому не вчера, а очень давно, клоун.

тебе, и видимо тем с кем ты работаешь такое и не снилось, вы бесконечно далеки от этого.

еще, в отличие от твое донного колхоза у меня коммиты всех разрабов в CI/CD тестируются параллельно на тестовых БД точно той же версии в той же конфигурации, с теми же расширениями. И я сделал это собственноручно. У меня разрабы не тестируют проект под одну базу против другой, такое просто невозможно, это абсурд, да в самом проекте ни один sql не выполнится. Более того - то что делаешь sqlite или чем там - это методологический неверно. Это не тестирование - это дичь, нужно быть дебилом чтобы не понимать это.

Я точно зубы обломал об переписывание процедур Sybase на функции PostgreSQL.

Жесть конечно. Но тут спор был в контексте переноса с mysql на postgres запросов, которыe генерит деревяшка ORM. И требуется такое раз в жизни, и то не факт.

Этих функций quote, quoteIdent и основанных на них prepared statements (замен плейсхолдера) в «драйвере» должно быть достаточно, чтобы встроить строку параметром.

Ну пусть проверяют и на клиенте, я не возражаю. Только это не повод тащить мегакомбайн ORM. С ним такая засада, что если схема простая, то стреляем из пушки по воробьям. А если сложная, то пушка оказывается картонной на деле.

Для меня эти вопросы типа sql-injection были выяснены более 20 лет назад. Удивительно что ты не понимаешь настолько элементарных вещей, то есть твой уровень получается - это.. стажер что ли? Или ниже?

Короче, ты должен публично извиниться.

Это совершенно не важно (даже если бы они там были), но я не помню чтобы там были некие валидаторы, о которых ты балаболишь.

Специально прошелся отладчиком по цепочке исполнения ларавель ->select(), и всё равно не обнаружил их. И кстати я этот код более или менее помню, в то время как ты его никогда и не читал.

https://github.com/laravel/framework/blob/f21afbcd52067a3cd9ff249b42800058e4bfcc73/src/Illuminate/Database/Connection.php#L747

Как видно, только два типа данных подвергаются манипуляциям, строки не в их числе, остальное идет как есть.

То есть, никаких валидаторов, это просто твоя выдумка.

Что касается приведенного тобой примера кода.

Во-первых, проблема не воспроизводится.

Но что куда более важно (ты ведь спорил о ценности ORM в разрезе безопасности), отправка запроса через laravel Connection приводит к точно такому же результату как и напрямую через PDO.

Если прохода отладчиком было бы даже не достаточно, то данный факт - эквивалентность всех эффектов отправки твоего запроса напрямую и отправки через - еще одно подтвержение.

#[DoesNotPerformAssertions]
#[Test]
public function dbtest1() {
    $govnovelDb = DB::connection();
    $pdo = $govnovelDb->getPdo();

    $pdo->query("set names 'gbk';");
    $stm = $pdo->prepare("
        with test(x, name) as (
            values (1, 'a'), (2, 'b')
        ) select * from test where name = ?
    ");
    $stm->bindValue(1, "\xbf\x27 OR 1=1 /*");
    $stm->execute();

    // PDOException: SQLSTATE[22P05]: Untranslatable character: 7 ERROR:  character with byte sequence 0xbf 0x27 in encoding "GBK" has no equivalent in encoding "UTF8"
    // CONTEXT:  unnamed portal parameter $1

    // лог субд:
    // │2025-02-13 19:18:50.598 MSK [2882996] ERROR:  character with byte sequence 0xbf 0x27 in encoding "GBK" has no equivalent in encoding "UTF8"
}

#[DoesNotPerformAssertions]
#[Test]
public function dbtest2() {
    $govnovelDb = DB::connection();

    $govnovelDb->statement("set names 'gbk';");
    $govnovelDb->select("
        with test(x, name) as (
            values (1, 'a'), (2, 'b')
        ) select * from test where name = ?
    ", ["\xbf\x27 OR 1=1 /*"]);

    // PDOException: SQLSTATE[22P05]: Untranslatable character: 7 ERROR:  character with byte sequence 0xbf 0x27 in encoding "GBK" has no equivalent in encoding "UTF8"
    // CONTEXT:  unnamed portal parameter $1

    // лог субд:
    // │2025-02-13 19:18:13.440 MSK [2882460] ERROR:  character with byte sequence 0xbf 0x27 in encoding "GBK" has no equivalent in encoding "UTF8"
}

Более того, как видно из лога СУБД, запрос через laravel connection доходит до субд, то есть не прехватывается никаким якобы защитами laravel. Ровно тоже что при отправке через PDO.

Если бы Твой ГОВНОвель ORM защищал от sql-injection, то почему запрос через него прошел полностью эквивалентно такому же напрямую через PDO?. Очевидно, потому что ты ПУСТОЙ КЛОУН.

Другими словами, твои заявления

У вас большие пробелы в знаниях, нормальный ORM фильтрует данные не позволяя попасть иньекции тк там есть валидаторы.

как и все последующие твои заявления являются пустой брехней и только выдают твою некомпетентность.

Это дело твоей чести сейчас признать свою некомпетентность и извиниться передо мной.

Про ORM плюсую.

Сначала они говорят «теперь вам не нужно знать SQL, вы просто пишите на своём языке программирования», а потом оказывается, что в любой непонятной ситуации нужно включать отладочный вывод сгенерированного SQL, быть способным понять что с ним не так, так ещё и вместо того чтобы просто исправить, подбирать какими методами и аннотациями ORM можно добиться правильной генерации SQL.

Было нужно знать основной язык программирования и SQL, теперь нужно знать основной язык программирования, SQL и ORM.

Зато можно быстро напрототипировать CRUD, который будет непригоден для прода из-за N+1 problem.

Смена СУБД действительно у подавляющего большинства проектов не происходит за всё их время жизни. А если происходит то всё равно является очень болезненным и ломающим изменением, потому что сложный проект не обходится без использования всяких расширений SQL специфичных для СУБД, иначе просто не получится выжать максимум производительности (в свою очередь именно СУБД обычно хуже всего масштабируется горизонтально, поэтому именно там важнее всего оптимизации).

А если никаких vendor-specific вещей не использовалось и сервис был простым, то может и на уровне SQL запросов хватить совместимости с незначительными изменениям.

По поводу защиты от SQL injection: просто не использовать СУБД и драйвера СУБД не умеющие в prepared statement и ни в коем случае не конкатенировать никаких пришедших извне вещей в SQL запрос. В 99% случаев использовать жёстко заданные запросы, в 1% случаев составлять запрос из заранее захардкоженных кусочков (например, когда нужна фильтрация по произвольному набору полей) и очень тщательно тестировать все граничные случаи.