Замена списка выбираемых полей на count(*) в SQL

[Valick]

grigori, ты весь энтузиазизм на корню порезал

 

[Фанат]

WMix + with + case + over + udf я знаю

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

$count_query = /*SELECT count(*) skipped */ "FROM T1 INNER JOIN bar on T1.f2!=bar.foo";
$data_query = 'WITH cte AS (SELECT foo FROM bar) SELECT f1, f2 from T1 where cte.foo != f2 ORDER BY f1' /* LIMIT :limit offset :offset will be added as agreement*/;
new Pagination($pdo, $count_query, $data_query);

ну так оно фактически так и делает, просто есть маленькая маггия для простых запросов

 

[WMix]

ну вот для этого случая и предусмотрен ручной режым

сделай и то и другое, и переключай режымы по аргументу $турбо=false
заодно и перформанс проверишь на простых запросах

 

[ksnk]

Библиотека, которая иногда, на некоторых запросах будет генерировать неправильный SQL и грохаться с ошибкой как-то не очень удачна, imho
Можно попытаться обеспечить работоспособность библиотеки при любых входных SQL. Просто отключить генерацию исключения в PDO при выполнении запроса-счетчика.
В случае, если произошла ошибка - ругаемся в лог или еще куда и тупо выполняем исходный запрос без лимита, подсчитывая счетчик вручную. При некоторой ловкости рук - можно результат запроса закэшировать, чтобы его еще раз не выполнять, если это, конечно, в природе возможно...

 

[Valick]

ksnk, львиная (если не все) доля падений произойдёт на уровне написания и отладки кода. Это же "для бедных" и "лайт-вершин".

 

[ksnk]

ksnk, львиная (если не все) доля падений произойдёт на уровне написания и отладки кода. Это же "для бедных" и "лайт-вершин".

Не все поддается отладке. Вообрази - сделался сайт, со страницей поиска по фильтрам, к нему прикрутили библиотечку и разработчик все проверил и радостно потирая ручки удалился в светлую даль. Через некоторое время потребовался новый комплект фильтров, вроде все просто - добавь условия в sql... Что может пойти не так ?

 

[WMix]

Что может пойти не так ?

добавь условия в sql подразумевает и протестить

 

[grigori]

главный вопрос - стоит ли изучение этой тулзы экономии сил на написание ручками count-запроса

 

[WMix]

На самом деле мотивация понятна, таблица огромная, ищем оптимальные пути.
я к тому что если уж делать то делать для всего, и только для особых случаев исключения.
ну и был бы для всех случаев select count(*) from (sql), а для особых, где запрос простой, но скорость узкое место с заменой полей.
это вроде достаточно прозрачно.

написании ручками count-запроса

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

 

[fixxxer]

Можно попытаться обеспечить работоспособность библиотеки при любых входных SQL

Очевидно, это возможно только в двух случаях:
1) query builder, который сам строит известное ему подмножество sql, так уже сделано в том же laravel
2) полноценный парсер sql в ast

Регулярками не стоит даже пытаться.

On a side note, я не вижу особого смысла в generic пагинаторе, манипулирующем sql. Для простых запросов есть query builder. С трехэтажными же зачастую и с большим offset-ом будут проблемы с производительностью, и в таких случаях делается не пагинатор, а всякие там show more. Да и даже если не так, тот, кто способен написать эффективный трехэтажный запрос, уж точно в состоянии и пагинатор к этому приделать.

 

[weregod]

Оффтоп, на днях пришлось изучить китайский QB, так гордился собой и чутка похвасталсо перед заказчиком, а потом оказалось, что inner join убивает ф-л, понял, что в драйвере конкретной БД лучше руками ((

 

[grigori]

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