Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
нужно сделать pagination по вот такому запросу.
SELECT p.id, p.autor, p.date, p.short_story, SUBSTRING(p.full_story, 1, 15) as full_story FROM `dle_post` WHERE `approve` = 1 AND `allow_main` = 1 AND `date` < 12-05-28 17:14:26 ORDER BY `fixed` DESC, `date` DESC
Переделать под Fluent Query Builder не выходит, а через Paginator::make($results, $total, $per_page) непонятно что за значение $per_page.
Не в сети
через Paginator::make($results, $total, $per_page) непонятно что за значение $per_page.
Это количество записей на страницу, вроде как в LIMIT page, par_page.
Не в сети
Paginator::make($results, $total, $per_page) :
$results - результат запроса
$total - всего
$per_page - на странице
но выводит одно и тоже на каждой странице.
Хотел решить проблему через Fluent Query Builder, но не строиться такой запрос.
-----------------------------------------------------
Всё таки построил запрос через Fluent Query Builder, с помощью метода ->select() сделал выборку, но от SUBSTRING(p.full_story, 1, 15) as full_story пришлось отказаться.
Изменено boyxil (30.05.2012 11:39:49)
Не в сети
...но от SUBSTRING(p.full_story, 1, 15) as full_story пришлось отказаться.
Да, думаю такое он не осилит. Есть DB::raw(), но в списке полей едва ли его можно применить. А тебе обязательно такую хитрую форму использовать? По идее лучше сделать отдельное поле, где будут хранится те 15 символов full_story, чем постоянно обрезать при выборке - это и для производительности лучше, и индекс можно будет поставить.
Не в сети
По идее лучше сделать отдельное поле, где будут хранится те 15 символов
На самом деле для нормального сервера СУБД всё ровно наоборот: обработкой в памяти можно пренебречь, а короткие строки БД лучше кэшируются. Уж поверьте моему опыту СУБД-шника.
Не выдержала душа поэта, зарегистрировался. :-)
Не в сети
На самом деле для нормального сервера СУБД всё ровно наоборот
Хочешь сказать, что БД не высчитывает каждый раз такие хитрые поля? Она их кэширует что ли?
Не выдержала душа поэта, зарегистрировался. :-)
Гы, привет
Не в сети
Хочешь сказать, что БД не высчитывает каждый раз такие хитрые поля?
Высчитывает. Но в СУБД как в ФП-системе экономия ресурсов заключается в декомпозиции и хранении минимально необходимых данных и пренебрежением к накладным расходам на вычисление значений. Тем более, в пределах одной строки (курсора).
Если Laravel не позволяет использовать конструкцию, предложенную boyxil -- это концептуальный недостаток и повод авторам Laravel задуматься над архитектурой.
Не в сети
Погодите, зачем такие сложности, есть же DB:query() , а результат можно отпажинировать Paginator::make.
Ни одна из изкоробочных ORM не держит такие сложные запросы, их же в любом случае проще писать на SQL, чем упихивать в прокрустовы рамки местных кверибилдеров или орм.
Не в сети
Ни одна из изкоробочных ORM не держит такие сложные запросы, их же в любом случае проще писать на SQL, чем упихивать в прокрустовы рамки местных кверибилдеров или орм.
Согласен с medar, это тот случай, когда на 20% редкоиспользуемых случаев (читай - продвинутых) пришлось бы потратить 80% времени и не известно, как бы потом такая ORM могла бы использоваться. В Laravel ORM очень лёгкая и простая при том, что покрывает большинство возможностей, да и не претендует на полную абстракцию от БД. SUBSTRING() к их числ явно не относится.
Не в сети
Всё таки сделал запрос через Fluent.
DB::table('post')
>select(array('id', 'autor', 'date', 'short_story',DB::raw('SUBSTRING(full_story, 1, 15) as full_story'), 'xfields', 'title', 'category', 'alt_name', 'comm_num', 'allow_comm', 'allow_rate', 'fixed', 'rating', 'vote_num', 'news_read', 'votes', 'flag', 'editdate', 'editor', 'reason', 'view_edit', 'tags'))
->where('approve','=','1')
->where('allow_main','=','1')
->where('date','<',date("y-m-d H:i:s"))
->order_by('fixed', 'DESC')
->order_by('date', 'DESC')
->paginate(5);
Не в сети
Не в сети
Страницы 1