Тут 3 запроса
http://docs.doctrine-project.org/projects/...pagination.html
Перевести на русский толком не могу, потому что не понимаю смысла описанных действий, потому и открыл тему. Короче, как смог
Запрос с count и DISTINCT
Субзапрос с DISTINCT для поиска всех сущностей текущей страницы
Запрос с WHERE IN с целью получить результат для всех (этих) сущностей
У меня пагинатор у меня такой. Количество строк берется из данных о коренной таблицы когда нет условия. Потому что больше или меньше строк ни при каких условиях соединения не получится. Таким образом рассчитать количество страниц можно еще до запроса. Если в запросе есть условие - where - это когда поиск или фильтр задействованы, то приходится второй раз запрашивать сколько там получилось при подсчете без лимита в первый, основной запрос.
Никаких DISTINCT и WHERE IN и рядом не стояло. Если кто-то понимает сам смысл этой схемы, объясните пожалуйста.
Полная Версия: Доктрина пагинатора из трех запросов
100% ЭТИПМ тут никто не пользовался. 100% никто не полезет проверять что там дается. Думаю это последняя месага в этом посту.
redreem
ты наверно уже обратил внимание на этого товарища - у него однозначно есть пунктик на счёт sql
мы рады новым участникам, всегда (по началу)
но давайте не забывать - что это форум php
это совсем не говорит о том что здесь не решаются вопросы sql - но эти так же не значит - что отвечая в каждом топике - нужно сводить всё к sql имхо.
_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker
ты наверно уже обратил внимание на этого товарища - у него однозначно есть пунктик на счёт sql
мы рады новым участникам, всегда (по началу)
но давайте не забывать - что это форум php
это совсем не говорит о том что здесь не решаются вопросы sql - но эти так же не значит - что отвечая в каждом топике - нужно сводить всё к sql имхо.
_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker
У обоих нет ответа, но они все равно ответили. Так можно лихо заполнить любую борду. Каждый сочтет своим долгом написать " а я тоже не знаю" и жырный топик на блюдечке.
Это надо рассматривать сам класс. Что именно не понятно? Перевод? тебе статью перевести?
Ага, переведите мне на русский вот эту часть
| Цитата |
| If you have complex fetch-join scenarios with one-to-many or many-to-many associations using the “default” LIMIT functionality of database vendors is not sufficient to get the correct results. |
с учетом изложенного тут http://dev.mysql.com/doc/refman/5.0/en/inf...tion_found-rows
Хотелось бы узнать по какой причине "not sufficient to get the correct results" может призойти как пишут доктринеры.
Не считая таких самоочевидных причин как UNION'ы
доктрина.... ага... я смотрел доктрину-77 и считаю чо буржуев нада мачить! 
Вам нужна ветвящаяся логика count для пагинатора а зависимости от запроса? Если я все верно понял, то это можно сделать либо реализовав свой пагинатор либо расширив существующий Doctrine\ORM\Tools\Pagination\Paginator:
namespace My\Tools\Paginator
use Doctrine\ORM\Tools\Pagination\Paginator as ORMPaginator
class Paginator extends ORMPaginator
{
private $_count;
public function count()
{
if ($this->_count === null) {
if ($this->getQuery()->getDQLPart('where') !== null) {
$this->_count = parent::count();
} else {
//ваш код пполучения числа записей
}
}
return $this->_count;
}
}
Что за логика? Я просто хотел узнать у тех кто в курсе за каким чертом у доктринеров такие чудные методы определения общего числа строк в запросе без учета кляузы LIMIT.
dr.nomore, так ведь по ссылке, которую вы сами же и привили, это и описывается. Давайте с примерами )
Вот запросы, который делает доктрина для вывода пагинатора:
1.Получает количество записей по условию:
2. Если сущности имеют связи многие ко многим или один ко многим (из-за этого неверно будет работать лимит (потому что join)),то выполняется запрос, который получает идентификаторы (первичные ключи) строк в таблице:
3. И последний запрос - получает данные для маппинга.
Вот запросы, который делает доктрина для вывода пагинатора:
1.Получает количество записей по условию:
SELECT COUNT(*) AS dctrn_count FROM (
SELECT DISTINCT id0 FROM (
SELECT some_fields
FROM CatalogProducts c0_
WHERE c0_.discriminator IN ('brokers_event')
ORDER BY c0_.marked DESC
) dctrn_result
) dctrn_table
2. Если сущности имеют связи многие ко многим или один ко многим (из-за этого неверно будет работать лимит (потому что join)),то выполняется запрос, который получает идентификаторы (первичные ключи) строк в таблице:
SELECT DISTINCT id0 FROM (
SELECT some_fields
FROM CatalogProducts c0_
WHERE c0_.discriminator IN ('brokers_event')
ORDER BY c0_.marked DESC
) dctrn_result
LIMIT 2 OFFSET 0
3. И последний запрос - получает данные для маппинга.
SELECT some_fields
FROM CatalogProducts c0_
WHERE (c0_.id IN (?) AND c0_.id IN (?)) AND c0_.discriminator IN ('brokers_event')
ORDER BY c0_.marked DESC
| Цитата |
| Если сущности имеют связи многие ко многим или один ко многим (из-за этого неверно будет работать лимит (потому что join)), |
Это кто придумал? Мануал ни о чем таком не предупреждает. В этом и заключался мой вопрос о запросах.
Стандартно делается 2 запроса. 1 с инструкцией на подсчет (SQL_CALC_FOUND_ROWS) и заданным LIMIT в конце, и второй взять этот текущий подсчет, например: 'SELECT FOUND_ROWS() as query_rows;' Синтаксис соединения таблиц роли играть не должен. LEFT JOIN может дать больше строк чем INNER JOIN - СУБД подсчитает все правильно, иначе и быть не может. Иначе получится что вы вообще никогда не узнаете сколько строк в результате получилось, если их нельзя подсчитать из-за JOIN.
Проблемы могут возникнуть из-за UNION. Что интуитивно понятно и мануал подтверждает предупреждая и рассказывая как правильно считать без учета лимита с объединением.
Но при чем тут join я так и не понял ни разу.
Что касается процитированных запросов, то из растактировки в статье уже понятно что будет чудовище. WHERE IN( на стопицот id's)...
Какие то все больно вспыльчивые 
_____________
Вязание xe4.ru спицами.
Сайт для тестов (подопытный №543)
_____________
Вязание xe4.ru спицами.
Сайт для тестов (подопытный №543)
| Цитата (dr.nomore @ 10.11.2013 - 05:11) |
| Мануал ни о чем таком не предупреждает. |
разве не об этом:
| Цитата (http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/tutorials/pagination.html) |
| If you have complex fetch-join scenarios with one-to-many or many-to-many associations using the “default” LIMIT functionality of database vendors is not sufficient to get the correct results. |
Одуреть. Я об этом и задаю вопрос с первого поста: на каком основании доктринеры написали процитированную вами хрень?
Мануал вот он какой http://dev.mysql.com/doc/refman/5.0/en/inf...tion_found-rows - ни одного вхождения слова join. Это о чем-то говорит?
Короче по совокупности отсутствия доказательств доктринерский пагинатор пока что в категории "бред укуренного стрептококка".
Мануал вот он какой http://dev.mysql.com/doc/refman/5.0/en/inf...tion_found-rows - ни одного вхождения слова join. Это о чем-то говорит?
Короче по совокупности отсутствия доказательств доктринерский пагинатор пока что в категории "бред укуренного стрептококка".
dr.nomore,ну вот мы и подобрались к истине. Возникает встречный вопрос: Почему вы об этом спрашиваете не у разработчиков доктрины (или у доктрина-людей) а на не имеющем к ней (доктрине) никакого отношения форуме?
Предположу лишь то, что эта orm работает не только с mysql (http://www.doctrine-project.org/blog/database-support-doctrine2.html) и так не дающая вам покоя "особенность" не что иное как следствие этого факта.
Предположу лишь то, что эта orm работает не только с mysql (http://www.doctrine-project.org/blog/database-support-doctrine2.html) и так не дающая вам покоя "особенность" не что иное как следствие этого факта.
Здесь расположена полная версия этой страницы.