Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Добрый день.
При формирование сырого запроса, возникает ошибка.
Запрос в коде выглядет так:
// SELECT * FROM categories WHERE category_id IN (480,479)
DB::select('SELECT * FROM categories WHERE category_id IN (?)', [implode(',', $сategories)]);
Вылетает ошибка
Invalid text representation
: 7 ERROR: invalid input syntax for integer: "480,479" (SQL: SELECT * FROM categories
WHERE category_id IN (480,479))</span>
Полагаю, ошибка возникает, когда laravel хочет подставить вместо ? строку "480,479", которая по себе не является int.
Как передать массив id для селекта в таком случае, в чем подковырка?
Не в сети
Мастер
Писарь
DB::table('table_name')->whereIn('category_id', [1,2,3])->get();
у меня любой сырой запрос === увольнение.
Не в сети
Мастер 
Во-первых, не надо использовать сырые запросы (DB::…), надо использовать Eloquent, т.к. он намного удобнее.
Во-вторых, действительно, ошибка из-за того, что «?» это всегда один параметр, числа через запятую трактуются как одно «не-число». Если уж использовать DB::select (хотя зачем, для такого-то простого запроса?), то что-то вроде:
if ($categories) {
$ph = '?'.str_repeat(', ?', count($categories) - 1);
DB::select('SELECT * FROM categories WHERE category_id IN ('.$ph.')', $сategories);
}
Не в сети
МастерПисарь
}%Во-первых, не надо использовать сырые запросы (DB::...), надо использовать Eloquent, т.к. он намного удобнее.
Во-вторых, действительно, ошибка из-за того, что "?" это всегда один параметр, числа через запятую трактуются как одно "не-число". Если уж использовать DB::select (хотя зачем, для такого-то простого запроса?), то что-то вроде:
%%(php)
if ($categories) {
$ph = '?'.str_repeat(', ?', count($categories) - 1);
DB::select('SELECT * FROM categories WHERE category_id IN ('.$ph.')', $сategories);
}
%%
Ну, так как речь шла о "сырье", и если нет возможности испотльзовать ORM, то я показал как можно, НО конечно же надо использовать все преимущества ORM.
Не в сети
Мастер Не в сети
у меня любой сырой запрос === увольнение.
Отзываю свое резюме. Но поинтересуюсь: а за что такого страшного в старом добром SQL?
Как-то вот заметил я, что ОРМ-ы приходят и уходят, а мой (почти) ровесник остается.
Не в сети
Мастер
- Но поинтересуюсь: а за что такого страшного в старом добром SQL?
В том, что где сырой запрос, там и SQL injection. Что мешает вопрошающему вместо моего кода
if ($categories) {
$ph = '?'.str_repeat(', ?', count($categories) - 1);
DB::select('SELECT * FROM categories WHERE category_id IN ('.$ph.')', $сategories);
}
использовать «оптимизированную версию»
if ($categories) {
DB::select('SELECT * FROM categories WHERE category_id IN ('.join(', ', $сategories).')');
}
- Как-то вот заметил я, что ОРМ-ы приходят и уходят, а мой (почти) ровесник остается.
А возраст не гарантия, скорее наоборот. Не так давно у eBay (тоже возраст огого) нашли SQL injection. Тоже, поди, ORM приходили и уходили, а сырые запросы с дырой оставались.
Не в сети
hzone пишет:у меня любой сырой запрос === увольнение.
Отзываю свое резюме. Но поинтересуюсь: а за что такого страшного в старом добром SQL?
Как-то вот заметил я, что ОРМ-ы приходят и уходят, а мой (почти) ровесник остается.
Ну, базист, конечно же, не понял бы :-)
Видимо, имелось ввиду, что увольняют именно за незнание ORM, что, в некоторых случаях, вполне логично выглядит.
Правда, не совсем понятно, отчего так сурово, особенно, с учетом того, что кандидат на увольнение аж умеет писать сырые запросы?
Не проще ли ему пару ссылок дать? Я так, из интереса.
Не в сети
Не так давно у eBay (тоже возраст огого) нашли SQL injection. Тоже, поди, ORM приходили и уходили, а сырые запросы с дырой оставались.
Вот лично мне не хотелось бы расплачиваться значительными ограничениями за незначительное усиление надежности.
Не в сети
Вот лично мне не хотелось бы расплачиваться значительными ограничениями за незначительное усиление надежности.
Ну какие там значительные ограничения? :-) Вы, простите, что, биллинг для МТС пишете? :-)
Не в сети
Ну какие там значительные ограничения? :-)
Не знаю.
Я понимаю, что ignorantia non est argument. Просто чует сердце-вещун: должны быть серьезные ограничения.
Вот изучу (куда деваться) этот ОРМ - и, может, продолжу эту тему.
Не в сети
Просто чует сердце-вещун: должны быть серьезные ограничения.
Ну, может и есть... Знаете, есть такие запросы, на пару страниц.... Но здесь же web-ремесленники, а не программисты баз данных. И hzone тут в своем праве - есть некие стандарты, а не "мне так удобнее, потому что я это знаю, а учиться не хочу".
Не в сети
"мне так удобнее, потому что я это знаю, а учиться не хочу".
Так вопрос не стоит.
Я начинаю изучать ОРМ - и думаю, мои аргументы не заставят себя ждать. Понадобится какой-нибудь SELECT ... INTO или что-то другое, чего не выразить ОРМ-ом.
А пока умолкаю за отсутствием аргументов.
Не в сети
Отзываю свое резюме. Но поинтересуюсь: а за что такого страшного в старом добром SQL?
Как-то вот заметил я, что ОРМ-ы приходят и уходят, а мой (почти) ровесник остается.
Читаемость кода, стоимость разработки и поддержки проекта. Ты пробовал читать чей-то сложный запрос в БД? Сколько у тебя времени уходит на то, чтобы понять как это работает? Вот ты оставил время и энергию (т.е. деньги заказчика), разобрался, добавил фичу/пофиксил баг и забыл. Через три месяца лезешь в этот запрос и опять приходится разбираться полностью с нуля.
Еще ситуация. Ты изменил в одном месте код запроса и у тебя рухнуло отображение данных в нескольких местах. А вот работа с коллекциями стандартизирована. Ты можешь взять чужой проект и с ходу работать с данными, потому что всегда знаешь какой там будет формат данных.
Эту проблему можно частично решить репозиториями (без них простыни сырого SQL - это вообще говнокод), но это, по своей сути, создание своей недо-ORM. Зачем изобретать велосипед, когда уже есть готовые, протестированные и универсальные решения?
В ORM все эти проблемы сведены до минимума. Здесь читаемость на высоте, потому что код - почти предложения на английском.
Если честно, я вообще не понимаю как в 2016ом можно до сих пор писать сырые запросы при наличии прекрасных проверенных годами ORM.
Вообще, чтобы понять разницу между ООП и процедурным кодом, ORM и сырым SQL нужно сделать хотя бы один действительно сложный проект с множеством связей. Чем сложнее проект, тем разница более заметна.
На StackOverflow часто вижу вопросы от новичков с простынями сырого SQL (в основном - это индусы) и никогда желания в это лезть и помогать нет. И им почти никто не пытается помочь, потому что человек сам не понимает что в его коде происходит и не пытается понять. Его задача - сделать и забыть, о читаемости и поддержке кода он не думает вообще.
Изменено AlexeyMezenin (15.11.2016 14:44:55)
Не в сети
И им почти никто не пытается помочь, потому что человек сам не понимает что в его коде происходит и не пытается понять. Его задача - сделать и забыть, о читаемости и поддержке кода он не думает вообще.
Точно. Причем сделать не самому, а чтобы за него сделали. Задать вопрос и дождаться ответа. Работает - и ладно.
Не в сети
Мастер
- Здесь читаемость на высоте, потому что код — почти предложения на английском.
- Вообще, чтобы понять разницу между ООП и процедурным кодом, ORM и сырым SQL нужно сделать хотя бы один действительно сложный проект с множеством связей. Чем сложнее проект, тем разнциа более заметна.
У каждого свои аргументы, и на мой взгляд эти — не основные. SQL значительно более «предложение на английском», чем код на ORM. SQL в конце концов стандартизирован, а разные ORM имеют разную форму записи, имена методов и так далее. Даже у разных версий Laravel есть отличия.
Поэтому сложные запросы как раз куда лучше писать в чистом SQL — это всякие INSERT... ON DUPLICATE KEY UPDATE, CREATE... SELECT, сложные SELECT с HAVING и тому подобное. Обычно, кстати, эти запросы нестандартны и работают только в MySQL (PgSQL, …), поэтому ORM их не поддерживает.
Но таких запросов мало, в основном работаешь с обычным «найти по дате и вернуть три поля из последних 10 записей». Для этого использовать SQL не нужно, т.к. действительно читаемость падает, ибо SQL в коде мало отличается от HTML или JS, или CSS.
Из стандартизированности и прозрачности SQL вытекает и то, что чем больше проект, тем больнее ощущаются уровни абстракции. Модели, ORM — лишний уровень. Да, необходимый. Но это ни разу не упрощает вхождение в такой проект, хотя, если грамотно написано, может упростить его понимание. Но спорно.
Основная проблема — это безопасность. Я аж в ступор впал, когда прочитал «…за незначительное усиление надежности». SQLi были бичом сети вплоть до последнего времени. Это тот же buffer overflow в Си, только SQLi удалось побороть благодаря распространению ORM, а переполнение буфера до сих пор то и дело вылазит в новых проектах. Сырые запросы приводят к огромным проблемам, если их использует не какой-нибудь ветеран, который может держать огромный проект целиком в голове и точно знать, где может просочиться пользовательский ввод. Но стоит ему уйти, придёт обычный разработчик и вся безопасность пошла-поехала, т.к. тут у него экранирование забыто, там строка проскочила и привет — у топового интернет-аукциона находят SQLi на главной странице. И утекли миллионы данных пользователей, потому что их разработчик считал «незначительные улучшения надёжности» выше своего достоинства.
Каждый сырой запрос — это потенциальная дыра. Сколько запросов — столько дыр. По статистике вероятности после …цатого запроса помноженное на число доработок проекта и членов команды вероятность ошибки стремиться к единице. Оно вам надо?
Не в сети
Читаемость кода, стоимость разработки и поддержки проекта. Ты пробовал читать чей-то сложный запрос в БД? Сколько у тебя времени уходит на то, чтобы понять как это работает?
Запрос SQL - это предложение на английском языке. И если он тяжело читается - значит, плохо спроектирована база и/или автор запроса неправильно строит работу с базой. На мои сложные запросы никто не жалуется.
Вот ты оставил время и энергию (т.е. деньги заказчика), разобрался, добавил фичу/пофиксил баг и забыл. Через три месяца лезешь в этот запрос и опять приходится разбираться полностью с нуля.
Если я "разобрался и пофиксил" - значит, запрос переписан и читается как "я помню чудное мгновенье".
Еще ситуация. Ты изменил в одном месте код запроса и у тебя рухнуло отображение данных в нескольких местах.
Если мне за это объявят неполное служебное соответствие - я скажу, что счастливо отделался.
Ты можешь взять чужой проект и с ходу работать с данными, потому что всегда знаешь какой там будет формат данных.
Вот взял. Бьюсь, как рыба об лёд.
Кстати, уже могу назвать проблему, к которой привел ORM. Человек писал код, совершенно не заморачиваясь быстродействием. Индексы, партишины, view? Нет, не слышали. Все записи в массив, массив обойдем построчно, собирая чего-то там. Потом и о пагинации подумаем, если процесс еще не гавкнулся...
Если честно, я вообще не понимаю как в 2016ом можно до сих пор писать сырые запросы при наличии прекрасных проверенных годами ORM.
Ну хотя бы затем, чтобы легче понять, в чем проблема выполнения запроса. Вот не работает правильно код ORM - что ему, скоту, надо???
А выводишь текст запроса, который тщится выполнить скрипт - и "вот и он, больной зуб"
Вообще, чтобы понять разницу между ООП и процедурным кодом, ORM и сырым SQL нужно сделать хотя бы один действительно сложный проект с множеством связей.
Этого у меня не отнять.
Не в сети
Основная проблема - это безопасность. Я аж в ступор впал, когда прочитал "...за незначительное усиление надежности". SQLi были бичом сети вплоть до последнего времени.
Все известные мне (не по прессе, а от верных людей) взломы были делом рук людей, законно получивших все необходимые доступы для своего злодейства. Им не нужно было унижаться до SQL-инжекции.
и привет - у топового интернет-аукциона находят SQLi //на главной странице//. И утекли миллионы данных пользователей, потому что их разработчик считал "незначительные улучшения надёжности" выше своего достоинства.
Не поэтому. А потому, что он вообще ничего не считал. Это такая примета времени сегодня - "эффективный менеджер". Он - руководил.
Дал команду.
Каждый сырой запрос - это потенциальная дыра. Сколько запросов - столько дыр. По статистике вероятности после ...цатого запроса помноженное на число доработок проекта и членов команды вероятность ошибки стремиться к единице. Оно вам надо?
Мне - не надо. Я просто взял за правило экранировать все, что пихаю в запрос.
Не в сети
SQL значительно более "предложение на английском", чем код на ORM
А ты сравни запрос с десятком отношений с eager loading и сырой запрос. Предложение на английском VS тарабарщина с использованием английских слов.
SQL в конце концов стандартизирован, а разные ORM имеют разную форму записи, имена методов и так далее. Даже у разных версий Laravel есть отличия.
Я говорил о формате данных. При использовании сырых запросов каждый изобретает велосипед. Даже если используется массив, то структура массива у каждого человека разная. Коллекции же выдаются всегда стандартные.
SELECT с HAVING
Ты под сырыми SQL запросами имеешь ввиду Query Builder или все-таки сырые запросы?
Но таких запросов мало, в основном работаешь с обычным "найти по дате и вернуть три поля из последних 10 записей". Для этого использовать SQL не нужно, т.к. действительно читаемость падает
Мое мнение - как раз наоборот. При простых запросах вообще разницы ноль: сырой SQL или ORM. А вот при сложных - ORM выгодно отличается.
Не самый удачный пример, наглядно показывающий читаемость ORM и SQL, но что под рукой есть:
$this->where('id', $id)
->slug($slug)
->with([
'publications' => function($q) {
$q->where('verified', true);
},
'verifiedLanguages',
'countries',
'publications.tags'
])->first();Генерирует вот это:
select * from `users` where `id` = '4' and `slug` = 'John-Smith' and
`users`.`deleted_at` is null limit 1
select * from `publications` where `publications`.`user_id` in ('4')
and `verified` = '1'
select `tags`.*, `publication_tag`.`publication_id` as `pivot_publication_id`,
`publication_tag`.`tag_id` as `pivot_tag_id` from `tags` inner join
`publication_tag` on `tags`.`id` = `publication_tag`.`tag_id` where
`publication_tag`.`publication_id` in ('3', '4', '5', '6', '7', '9',
'12', '16', '17', '18', '20', '21', '22')
select `languages`.*, `language_user`.`user_id` as `pivot_user_id`,
`language_user`.`language_id` as `pivot_language_id`, `language_user`.`id`
as `pivot_id`, `language_user`.`verified` as `pivot_verified`,
`language_user`.`evidence_text` as `pivot_evidence_text`, `language_user`.`proficiency`
as `pivot_proficiency`, `language_user`.`created_at` as `pivot_created_at`,
`language_user`.`updated_at` as `pivot_updated_at` from `languages`
inner join `language_user` on `languages`.`id` = `language_user`.`language_id`
where `language_user`.`verified` = '1' and `language_user`.`user_id` in ('4')
select `countries`.*, `country_user`.`user_id` as `pivot_user_id`,
`country_user`.`country_id` as `pivot_country_id` from `countries`
inner join `country_user` on `countries`.`id` = `country_user`.`country_id`
where `country_user`.`user_id` in ('4')Конечно, кто-то может сказать, что SQL здесь более читаем, но я от проектов с сырыми запросами сразу отказываюсь, даже если оплата почасовая.
Это просто пример, который под рукой. Если здесь использовать полиморфные связи, работу с дополнителными полями в pivot и т.д., SQL будет выглядеть еще более нечитаемо.
Не менее важный момент: ORM запрос выше создает одну коллекцию с вложенными коллекциями и "пройтись" в представлении по всем данным - одно удовольствие. Если человек напишет сырой запрос, подобный показанному выше, почти всегда это будет отсебятина в виде nested массивов с неведомой структурой.
И еще плюсики в сторону Eloquent. Он на лету работает с датами как с Carbon объектами, Soft Deletes и прочими стандартными фишками, которые нужно создавать и поддерживать руками при использовании сырых запросов. А еще есть события, scopes, геттеры и сеттеры и пр. вкусности. )
Изменено AlexeyMezenin (15.11.2016 15:55:31)
Не в сети
tmanager, я правильно понимаю, что вся логика Ваших сообщений на форуме сводится к "нафиг нужны эти ORM, MVC, Laravel, если и без них было хорошо"?
Изменено Androbim (15.11.2016 15:44:10)
Не в сети
Кстати, уже могу назвать проблему, к которой привел ORM. Человек писал код, совершенно не заморачиваясь быстродействием. Индексы, партишины, view? Нет, не слышали.
Логика на уровне "новичок написал проект через зад с использованием ORM, значит ORM гомно"...
На счет индексов - я ни в одном проекте пока еще не собирал JS/CSS, не создавал индексы и пр. только потому, что никто не хочет за это платить, заказчики сами делают эти мелочи при тестировании приложения. Возможно, у тебя та же ситуация. Может и нет.
Вот не работает правильно код ORM - что ему, скоту, надо?
Может изучить ORM до той степени, чтобы понимать как это работает? У меня, когда ORM работает "не так", я смотрю в документацию, исходники Laravel и свой код, а не в сырые запросы. Да и смотреть в сырые запросы, генерируемые ORM - это совсем не то же самое, что писать приложение с использованием сырых SQL запросов.
Не в сети
Я всего лишь спросил совета, как мне в сыром запросе адекватно вставить переменную в условие IN().
Proger_XP, спасибо, такое предложение в инете встречал, но думал, что есть что-то типа плейсхолдеров, как в некоторых библиотеках работы с бд))
В моем случае, это первое знакомство с laravel, проект большой, но не биллинг для мтс, как кто-то упомянул.
Проект веду я один и поддерживать его буду я, а если после меня кто-то залезет в код не составит никакиех трудов в нем разобраться ибо каждый запрос обернут в функцию, название которой говорит само за себя. Не считаю это каким-то "непрофессионализмом" или чем-то другим. Сложно мне начать с ORM сразу на боевом проекте, все эти связи.. Я себя чувствую ограниченным в движениях. Работаю с postgres , есть выборки по json, массивам со сложными условиями.
Было сказано про "сырой запрос === увольнение". Иными словами, если ты рисуешь зеленым карандашом, ты не сможешь работать с нами над картиной пустыни, потому что мы рисуем синими карандашами. hzone, ты по многим моим топикам давал подсказки по laravel и спасибо большое. Но, как было бы полезнее провести своей команде мастер-класс и вывести на должный уровень, что делает руководителя, хорошим 
Масса людей пользуется ORM и конструкторами и мало понимает вообще как оптимизируется сам запрос. Дискуссий в интернете полно по сырым запросам и ORMам. Есть плюсы и минусы, каждый выберет подходящий вариант. Говнокод, вообще понятие субъективное по большинству своему, ибо это первое, что вы гворите, видя проект предыдущего программиста)
В доках ларавеля, есть текст для сырых запросов:
"Привязка параметров обеспечивает защиту от SQL-инъекций." Так как правильно считать, обеспечивает, но не так сильно как хотелось бы?
Изменено Fridz (17.11.2016 20:40:21)
Не в сети
Мастер
- В доках ларавеля, есть текст для сырых запросов:
- «Привязка параметров обеспечивает защиту от SQL-инъекций.» Так как правильно считать, обеспечивает, но не так сильно как хотелось бы?
Обеспечивает, но грань между сырым запросом с параметрами (безопасно) и сырым запросом без параметров (опасно) очень тонка. Выше я приводил пример, к чему может привести именно использования select..in без понимания разницы между параметрами и самим запросом.
- Но поинтересуюсь: а за что такого страшного в старом добром SQL?
В том, что где сырой запрос, там и SQL injection. Что мешает вопрошающему вместо моего кода
PHPif ($categories) {
$ph = '?'.str_repeat(', ?', count($categories) - 1);
DB::select('SELECT * FROM categories WHERE category_id IN ('.$ph.')', $сategories);
}использовать «оптимизированную версию»
PHPif ($categories) {
DB::select('SELECT * FROM categories WHERE category_id IN ('.join(', ', $сategories).')');
}
Я надеюсь, проблему во втором запросе видно без комментариев?
Не в сети
МастерПисарь
потехоньку разговор от темы скатывается к стоимости разработки, стоимости поддержки, и стоимости зелёнки от тумаков заказчика )))
объясните парню проще, например - попробуй забить 200 гвоздей в срок 1 час без молотка (инструмента, по аналогии ларавела).
- за 30 минут сломаешь руки, ноги и другие крепкие части тела
- за 29 минут заточешь камень
- работать тебе 1 минуту и дедлайн.
= потерял выгоду.
но всё равно делаь будешь, ибо договор.
и тут уже наступает момент потери твоего времени, которое при использовании молотка, ты мог бы потратить или на другого клиента или на трату полученной выгоды в угоду себе = это уже стоимость неустойки, равная стоимости получени очередной выгоды от нового клиента в период работы на старого клиента.
понятно объясняю?
а ведь ещё баги ловить, тестить, запускать в продакшен, обязательно всплывёт "ой забыл" от клиента или не дай бог от тебя...
ещё пример: струйные принтеры HP
- принтер стоит копейки.
- набор чернил в годовом эквиваленте = 5 принтерам (в зависимости)
это яркий пример-аналогия стоимости работы и стоимости вынужденной поддержки. одно без другого бессмысленно. а в сумме жаба душит 
Изменено hzone (18.11.2016 01:24:02)
Не в сети
Добрый день.
Решил не создавать новых тем. Только начал изучат Laravel и возник затык при переводе своих "старых" sql запросов в "ларавель правильные"
Вот один из
SELECT a.answer_id, at.type, a.value, ao1.type_other, ao1.other_value, ai.value as image, a.hidden, a.required
FROM answer a
LEFT JOIN answer_type at ON (a.answer_type_id = at.answer_type_id)
LEFT JOIN answer_image ai ON (a.answer_id = ai.answer_id)
LEFT JOIN ( SELECT at.type as type_other, question_id,answer_id, value as other_value
FROM answer_other ao JOIN answer_type at ON (ao.answer_type_id = at.answer_type_id)
WHERE ao.question_id = (int)$question_id
) ao1 ON (a.answer_id = ao1.answer_id)
WHERE a.question_id = (int)$question_id
ORDER BY a.sort_order
Как наиболее правильно это сделать? На ум приходит только raw.
Не в сети
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)