Update. Метод Folder::findRecursive возвращал слишком много файлов, в том числе и ненужных. Переписал немного, теперь опрашиваем только директорию с плагином и его контроллерами.

/**
 * Lists the names of controllers including plugin controllers
 * 
 * @return array
 */
static function listControllers()
{
    App::import('Core', array('File', 'Folder'));
 
    $controllers = Configure::listObjects('controller');
 
    $config = Configure::getInstance();
 
    foreach ($config->pluginPaths as $pluginPath)
    {
        $folder = new Folder($pluginPath);
        list($plugin_dirs) = $folder->read();
        foreach($plugin_dirs as $plugin_dir)
        {
            $pluginName = Inflector::camelize($plugin_dir);
            $folder->cd($pluginPath . $plugin_dir);
            $controllerFiles = $folder->find('.*_controller\.php');
            $folder->cd(Folder::addPathElement($folder->path, 'controllers'));
            $controllerFiles = array_merge($controllerFiles,$folder->find('.*_controller\.php'));
            foreach ($controllerFiles as $file)
            {
                $file = basename($file);
                $controllers[] = $pluginName . '.' .
                    Inflector::camelize(substr($file, 0, strlen($file)-
                    strlen('_controller.php')));
            }
        }
    }
    return $controllers;
}

Сегалович:

Ровно в этих рамках (борьба с «глупостью») мы относительно недавно реализовали алгоритм определения запросов и ответов, которые можно трактовать двояко: и как поиск эротического и порнографического содержания, и как невинный информационный запрос. Например, запрос [девочки] может быть поиском повести Людмилы Улицкой, а вовсе не «девочек по вызову». Для человека, ищущего Улицкую, ответ с порнографией не просто нерелевантен, он «явная глупость».

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

Было бы логично, если бы Яндекс подсовывал разным посетителям разные варианты выдачи, основываясь на данных предыдущих запросов, статистики из Метрики и т.д. Не специально для каждого пользователя, а для каких-то условных групп, типа «любитель клубнички», «книжный червь» или каких-то таких. А что? Статистика по запросам есть, статистика посещенных сайтов и проведенного на них времени — то же (Метрика, различные кнопки ТИЦ, блогов и т.д.) — нарисовать схему интересов пользователя можно. И потом соотнести с какой-то своей внутренней классификацией. А вот слова о том, что ответ не подвергается модификации — это, возможно, и временно. На паре «порно/непорно» алгоритм просто обкатывается.

Если Яндекс все-таки реализует модификацию выдачи в зависимости от вычесленных предпочтений пользователя — вот будет головная боль оптимизаторам! Почистил куки, походил по сайтам с пластиковыми окнами – получи выдачи про строительство и остекление балконов, почистил куки, походил по сайтам с программным обеспечением — получи выдачу про Windows. И все в ответ на один и тот же запрос «окошки».

Сегалович:

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

Садовский:

Чтобы было понятно, «котел» какого объема оценивается, подчеркну, что это речь идет о десятках тысяч запросов, которые мы проверяем таким образом. Мы проверяем первые 30 позиций по каждому запросу. Считайте: десятки тысяч запросов, умножить на 30 первых позиций, умножить на количество версий, – это десятки миллионов URL.

Мониторят конкурентов. Очевидно, Google, Bing и Рамблер. Наверное и Yahoo. Об остальных можно только догадываться. Составляют множество сайтов, попадающих в выдачу всех или бОльшей части конкурентов. Потом сравнивают со своими результатами. Конкретная позиция, наверное, не очень важна — главное присутствие в первых 30-ти результатах. Смотрят, какие сайты попали к ним — если различие сильное, это повод задуматься. Т.е. если после получения результатов от конкурентов оказывается, например, что 22 сайта присутствуют у всех, а у Яндекса только 5 из этих сайтов — это повод побеспокоиться.

Сразу возникает интересная идея — путь к первой странице выдачи Яндекса может лежать и через результаты выдачи его конкурентов.

Сегалович:

Так вот, практически все обращения в службу техподдержки – я думаю, в цифрах это будет более 90% – касаются именно таких сайтов из «серой зоны». Пишут грамотные аргументированные письма: «А вот смотрите, почему вы этот сайт выбросили, он качественный, контент уникальный, ссылки по теме. Объясните почему.» Цель таких писем – методом перебора уточнить безопасные границы в этой «серой зоне». Предприняли какое-то действие – смотрят результат. Если результат отрицательный, сайт попал под санкции, они пытаются получить от нас обратную связь, проанализировать причины.

Певцов:

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

Садовский:

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

Ну все уже догадались? Жаловаться на то, что сайт выпал из индекса, хотя соответствует «техническим параметрам» – ссылки, качество контента и т.д. – не надо. Ищите другую аргументацию. Вам же не робот отвечает, человек. И он понимает, что вебмастер беспокоящийся о технической стороне вопроса — не их союзник. И еще. Удалось убедить, что «сателлит» белый и пушистый? Будьте готовы к тому, что из под санкций могут выползти и «сателлиты» конкурентов. Любите жаловаться на «сателлиты» конкурентов, присутствующие в выдаче? Будьте готовы к тому, что вместе с ними пойдут ко дну и ваши такие-же.

Певцов:

уникальность контента совсем не определяющая вещь. О ней много говорят, но более важная характеристика – не уникальность, а полезность контента [и далее по тексту]

«У вас на сайте неуникальный текст! Ужас-ужас-ужас!» – страшилка. То есть, если скопировать все подряд, санкции будут. Но умеренное разбавление своих статей статьями, взятыми из других источников, может не повлечь никаких санкций. Таким образом, если где-то в интернетах нашлась удачная статья, подходящая сайту и автор не против ее распространения, можно спокойно скопировать ее к себе или процитировать. Ссылка на оригинал, как мне кажется, в данном случае будет лишним подтверждением «добрых намерений».

Четвертая часть о воровстве контента. Авторам стОит отдавать свои статьи в RSS. Не жмотитесь, отдавайте всю статью. Роботы, сканирующие блогосферу быстрее и чаще забирают контент. Если статья у кого-то скопирована, не надо расстраиваться, страница с этим текстом не первая в выдаче. Еще не факт, что посетителя заинтересует первый сайт. 2-5 место тоже хороши. И до конца первой страницы – нормально. Кроме того, скопированная страница может придать общий тематический вес сайту, подняв его по другим, похожим, низкочастотным запросам.

Торговля и обмен ссылками яндексоидов раздражают. Но, если уж они научились находить «продажные ссылки», то зачем банить всю страницу, она может оказаться вполне нормальной, а ссылки – результатом баловства наемного вебмастера. Ну неучитывали-бы тихонько эти самые ссылки молча. Дятлы бы продолжали бы заниматься бесполезным трудом и не искали бы каких-то иных методов воздействия на поисковик.

Ну вот как-то вот так. Спасибо, что дочитали до конца. :)

App::import('Model', 'MyModel');

Но загрузить контроллер так не получится. Получим сообщение об ошибке из-за невозможности найти базовый класс Controller. Вот найти класс Model кейк может, а Controller – нет. Во всяком случае 1.2.5. В версии 1.3 не пробовал.

Поэтому приходится загружать его явно и напрямую:

App::import('Core', 'Controller');
App::import('Controller', 'MyController');

Этот код приложения, изначально крутившийся по Cake 1.1, был переписан для какой-то беты Cake 1.2. С текущей версией, 1.2.5, он работает без проблем, но, возможно, нуждается в чистке.

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

Данные поступают из написанного куцего Datasource, скармливанются компоненту, который и выполняет разбор и приведение к общему виду, потом записываются в нашу таблицу.

Компонент подгружается динамически, в зависимости от поставщика. Все компоненты являются наследниками базового и реализуют метод parse. Этот метод базового компонента, если не перегружен, возвращает NULL — в этом случае в нашу таблицу ничего не записываем, переходим к следующей порции данных. Соответственно методы наследников тоже могут возвращать NULL при ошибке разбора, например, при отсутствии какого-либо ключевого поля.

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

Увы, все файлы с компонентами находятся в каталоге components. Зато после перегрузки можно к загруженному компоненту обращаться по имени базового:

$this->SupplierCsv->parse($data);

В коде контроллера загружается базовый компонент. Так как он нужен только в одном методе контроллера, в нем я его и загружаю:

if (!App::import('Component', 'SupplierCsv'))
    die('Cannot load SupplierCsv component');

Еще у базового компонента есть метод factory. Я не помню, почему я его статическим объявил, честно. :-) Он получает в качестве параметра ссылку на контроллер и название компонента для обработки данных от конкретного поставщика:

SupplierCsvComponent::factory($this, array('CsvComponentName'=>$component_name));

Теперь методы базового компонента, SupplierCsvComponent:

function startup(&$controller)
{
    $this->controller = $controller;
    $controller->SupplierCsv = $this;
}
 
static function factory(&$controller, $supplier)
{
    App::import('Component', $supplier['CsvComponentName']);
    $componentclass = $supplier['CsvComponentName'] . 'Component';
    $controller->SupplierCsv = new $componentclass;
    $controller->SupplierCsv->startup($controller);
}

ну и код метода startup дочерних классов:

function startup(&$controller)
{
    parent::startup($controller);
    $this->init = $this->name;
}

Решение неидельное, наверняка можно соптимизировать. Мне, честно говоря, заниматься этим не хочется. Просто потому, что я в итоге начну вообще все с нуля переделывать и менять логику. :)

Откровенно говоря, огород можно было бы и не городить. Можно через App::import() загрузить класс компонента, а потом какой-нибудь переменной контроллера присвоить экземпляр этого класса.

Наверное, я раньше грузил компонент, указывая его в массиве $components, потому и сделал такую навернутую схему.

А может мне не хотелось require_once использовать… Ну не помню. :)

Update: Если соберусь переписывать, надо будет рефлексию попробовать использовать. :)

В качестве кэша байткода и переменных я использую XCache. Но при запуске консольных приложений, он у меня не работает. Должен или нет, не знаю, не разбирался. Наверное, не должен, если подумать. :-) Просто отметил, что консольные приложения Cake, включая ‘cake bake‘ высыпают кучу ошибок, если XCache используется, как кэш по умолчанию. Поэтому в конфигурации кэша приложения (APP/config/core.php) на CakePHP добавляю маленькую проверку на тип API.

Вот как-то так:

if (PHP_SAPI == 'cli') {
  Cache::config('default', array('engine' => 'File'));
} else {
  Cache::config('default',
    array(
      'engine' => 'Xcache',
          'prefix' => 'mypfx_',
          'user'=>'IamAdmin',
          'password'=>'c00leztPass'));
}

Можно пользоваться константой PHP_SAPI или функцией php_sapi_name(), не важно.

http://www.oursite.com/controller/action.json

Чтобы Cake не пугался этого расширения и вызывал правильное действие (action), в файл APP/config/routes.php добавим строку:

Router::parseExtensions('json');

Теперь надо разобраться с разными представлениями наших данных, чтобы по запросам к /action и /action.json возвращались разные виды. Для этого нужен компонент RequestHandler. Подключим его либо в самом контроллере, либо в родительском AppController:

var $components = array('RequestHandler');

Теперь шаблоны для view и layout Cake будет искать в поддиректориях /json. Т.е для layout надо будет создать файл /views/layout/json/default.ctp:

<?php echo $content_for_layout; ?>

и файл для действия /views/controller/json/action.ctp. Какой-то такой:

<?php echo $javascript->object($data); ?>

Это все и без меня все знают, ничего нового тут нет. Разве что cakebaker советует воспользоваться Zend::Json вместо стандартного помощника Javascript, дескать Zend’овская библиотека автоматом кодирует некоторые спецсимволы.

Но есть одна тонкость, недостаточно отраженная в документации — заголовок ответа Content-type. По всем ожиданиям он должен быть ‘application/json’, как это определено в коде компонента RequestHandler.

Однако, если включен режим отладки, т.е. Configure.debug > 0, то RequestHandler устанавливает Сontent-Type в text/html без вариантов. Это, в общем-то описано в документации и докопаться до этого можно.

Но совершенно неочевидно, что если режим отладки выключить в коде самого action, написав

Configure::write('debug', 0);

то это ничего уже не изменит! RequestHandler устанавливает заголовок во время загрузки компонента. Его метод startup() вызывает метод renderAs(), который вызывает метод respondAs(). Таким образом шаблоны подключаются нужные, те, которые из директорий /json, а Content-Type неправильный.

Лично я, пока, в acton, который должен отдавать данные в json, явно вызывываю RequestHandler->respondAs() повторно:

if (Configure::read()) {
    Configure::write('debug', 0);
    $this->RequestHandler->__responseTypeSet = null;
    $this->RequestHandler->renderAs('json');
}

Это заставляет RequestHandler изменить заголовок Content-type еще раз. Можно похожий код, с проверкой типа запроса и установкой режима отладки и заголовков попробовать запихнуть, скажем, в beforeRender. Обратите внимание на грязный хак с установкой свойства __responseTypeSet в NULL. Метод respondAs сохраняет в эту переменную тип ответа и повторно не будет срабатывать, если он уже был вызван.

Яндекс.Метрика

Все как обычно — устанавливаете код на страницы своего сайта и наблюдаете статистику по посетителям. В отличие от GA, которая обновляется раз в сутки, Метрика показывает результаты практически в реальном времени, как Liveinternet — это гораздо удобнее.

Если сайт рекламируется с помощью Яндекс.Директ и на рекламируемом сайте установлен код для сбора статистики для Директа — это и есть код Метрики!  В этом случае можно уже не напрягаться, а смотреть отчеты.

Эта тема пару месяцев назад обсуждалась в ЖЖ сообществе ru_php, но как-то вяло. Попробую этим небольшим постом обобщить разные методики.

Самый простой метод: сначала SELECT COUNT(*), а потом, по результатам, либо INSERT, либо UPDATE. Если речь идет об обновлении одной записи на этом методе можно остановиться.

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

REPLACE — наиболее очевидный и самый неудобный. Сервер пытается вставить новую строку, если возникает ошибка с повторяющимся уникальным ключом, запись удаляется и потом снова добавляется новая. Увы, при этом значения тех полей, которые обновлять не надо сбрасываются в дефолтные. Использовать эту команду можно, если обновляется полностью вся запись, что случается редко. Например, если в таблице есть колонка `created`, содержащая дату создания записи, то REPLACE уже не подходит. Кроме того, в случае, если большинство записей заменяется, а не добавляется, получается конструкция INSERT-(ошибка)-DELETE-INSERT — три запроса!

INSERT … ON DUPLICATE KEY UPDATE … — этот вариант сильно интереснее. Сервер пытается вставить запись, если получает ошибку c дублирующимся ключом, обновляет поля, указанные в после UPDATE. Работает отлично, в документации сказано, что эта конструкция специально задумана для вставки множества записей. Но пара неприятных моментов есть.

1. Первый, как мне казалось, довольно экзотичный, но я с ним все-таки столкнулся. В конструкции INSERT можно в качестве источника данных использовать подзапрос SELECT. Но, в случае с INSERT … ON DUPLICATE KEY UPDATE, в подзапросе не должно быть группировки GROUP BY.
2. Второй момент для многих неважен. Если записей для обновления сильно больше чем новых, то получается все равно много лишних обращений к БД — ведь вся конструкция это сочетание INSERT-(ошибка)-UPDATE. Лучше, чем с REPLACE, но все же…

Долгое время я пользовался UPDATE, а потом проверял mysql_affected_rows() (в CakePHP это $DataSource->lastAffected(). То есть проверял количество обновленных записей и, если получал 0, добавлял запись. У этого метода есть очень существенный недостаток: если среди данных для обновления встречаются две одинаковых строки, то при повторном UPDATE сервер, как самый умный, не обновляет запись. Соответственно число обновленных записей, affected rows, при построчном переборе, будет равно 0 несмотря на то, что такая строка в таблице есть. Соответственно решение о вставки новой строки будет ошибочным.

Устав мириться с ожидаемым, но неприятным поведением mysql_affected_rows() я порылся в документации на MySQL и нашел еще одну функцию: mysql_info(). Она выдает обычную строчку со статистикой последнего запроса к БД, причем для разных типов запросов строчки разные. Для UPDATE выглядит так:

Rows matched: 40 Changed: 40 Warnings: 0

Зато содержит чрезвычайно ценную информацию: количество записей, которые попадают под условие для обновления. Это те цифры, что после слова ‘matched:‘. Ну, регулярное выражение для получения циферок из строки сами напишите? ;-)

P.S. У меня ощущение deja vu — мне кажется, что я уже писал похожий пост. Перерыл дневники — нет такого. Или это черновик был…

Я не люблю обновлять MySQL ни на своей машине, ни на сервере. Каждый раз гадаешь: «понадобится бэкап или или нет?» Поэтому имеет место некоторая несогласованность версий, на которую я не слишком сильно обращал внимание. До сегодняшнего вечера. Итак у меня в наличии на домашней машине MySQL 5.1.22-rc-community, win32. На сервере соответственно MySQL 5.0.45 из бокса CentOS 5.

Самая обычная таблица в БД, с самым обычным полем created типа DATETIME.

Однако запрос

SELECT
    COUNT(*) AS `count`
FROM
    `offers` AS `Offer`
WHERE
    `Offer`.`supplier_id` = 3 AND
    DATE(`Offer`.`created`) = '2009-03-12'

работает на них совершенно по-разному!

На домашней машине все, как ожидается, возвращается количество записей за 12-е число. На сервере — 0 записей. После некоторого яндексения в гугле, выяснилось, что на эти грабли, конечно же, наступал не я один и, в зависимости от версии, вернее, от релиза, обработка такого условия работает по-разному.

На домашней машине у поля DATETIME обрезается часть, содержащая время. На сервере наоборот, к выражению для сравнения добавляется ‘ 00:00:00′. :-/ Но отчего тогда не срабатывает функция DATE() все равно непонятно, это встроенный оптимизатор MySQL ее оптимизирует нафиг?

Много английских букв на близкую тему: http://bugs.mysql.com/bug.php?id=28929.

В соответствии с советами из мануала MySQL переделал запрос так:

SELECT
    COUNT(*) AS `count`
FROM
    `offers` AS `Offer`
WHERE
    `Offer`.`supplier_id` = 3 AND
    CAST(`Offer`.`created` AS DATE) = '2009-03-12'

все равно не работает! Единственный заработавший вариант выглядит так:

SELECT
    COUNT(*) AS `count`
FROM
    `offers` AS `Offer`
WHERE
    `Offer`.`supplier_id` = 3 AND
    SUBSTR(`Offer`.`created`,1,10) = '2009-03-12'

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

Самое неприятное в том, что заранее точно сказать будет-ли работать нормальное условие с DATE() на каком-то сервере нельзя. Можно только предположить.

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

Configure::write('App.Database.MySQLDateTimeExtractor', 'SUBSTR'); // or 'DATE'

В общем, надо повнимательнее к выборке дат.

Известно, что метод контроллера paginate() вызывает последовательно два метода модели — первый для подсчета общего числа записей, удовлетворяющих заданным условиям, и второй на выборку указанного числа записей начиная с заданной. Т.е. первый это фактически функция SQL COUNT(*), второй — SELECT … LIMIT n,m.

Именно из-за того, что вызовов методов больше одного, не срабаывает временная привязка/отвязка подчиненных моделей с помощью bindModel()/unbindModel(). Этим методам, для корректной работы с paginate() приходится передавать второй параметр, равный false. К счастью, еть ContainableBehavior, решающий эту проблему.

Эти запросы не всегда оптимальны и есть возможность улучшить производительность метода paginate() именно за счет оптимизации собственно самих запросов.

Для того, чтобы влиять на работу метода paginate(), в контроллере CakePHP предусмотрены вызовы двух специальных методов модели: Model::paginateCount() и Model::paginate(). Метод paginate() контроллера ищет у модели указанные методы и, если они определены, вызывает их. Если у модели методы не определены, вызываются стандартные Model::find(‘count’ …) и Model::find(‘all’,..), которым в качестве параметров передаются условия выборки, условия для Containable и все прочее.

Понятно, что определив эти методы в модели, все вместе или любой на выбор, можно творить все, что захочется. А сам метод Controller::paginate() (не путайте с нашим Model::paginate()!) тогда будет заниматься исключительно вспомогательной работой — опредять параметры для LIMIT и настраивать переменные вида (View). Самое главное, чтобы наш метод Model::paginateCount() возвращал (int) количество записей, а Model::paginate() — массив записей.

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

Model::paginateCount

Первым займемся методом для подсчета количества записей. Этот метод я уже описывал чуть более года назад, но то описание во-первых устарело, потому, что в итоге в CakePHP сменился синтаксис вызова COUNT(*), а во-вторых здесь я постараюсь дать более развернутое описание.

При вызове метода Model::paginateCount(), контроллер передает ему три параметра: $conditions, $recursive и $extra.

• (array) conditions — ассоциативный массив условий, такой же, как массивы условий для любых других методов модели. В нашем случае в него копируются условия из массива Controller::paginate['conditions'].
• (int) recursive — значение параметра $recursive. Если это значение установлено в переменной Controller::raginate['recursive'], то оно. Если нет, то берется из значения свойства Model::recursive
• (array) extra — ассоциативный массив всех остальных переменных, передаваемых в Controller::paginate, ‘contain’ (для ContainableBehavior), ‘fields’ и т.д. В общем, содержимое переменной Controller::paginate без первых двух параметров.

Хочу отметить, что никто не запрещает указывать в массиве Controller::paginate какие-то свои собственные ключи. Так что, если в методе нашего контроллера определить что-то типа:

$this->paginate['my-cool-param']='YES!';

то эта пара ключ-значение тоже попадет в параметр extra.

Чаще всего для разбивки на страницы используется модель, связанная с другими. Классический пример с моделью Article, которая принадлежит (belongsTo) модели Author. Для окончательного вывода нам нужны данные из обоих моделей, но для подсчета записей достаточно посчитать только записи в Article. Т.е. для подсчета строк достаточно выполнить COUNT(*) только для таблицы articles, без лишних JOIN’ов. MySQL работает гораздо веселее, когда удается обойтись без связанных таблиц. Для этого простого случая вполне можно вызывать $this->Article->unbindModel(array(‘belongsTo’=>array(‘Author’)))) и связанная модель Author не будет участвовать в подсчете, но будет в выборке результатов. Помните, что метод unbindModel() по умолчанию «отвязывает» модель только на один, следующий, запрос?

Но если связанных моделей много, что, надо помнить их все? Да и дергать unbindModel() перед Controller::paginate() что-то не улыбается. Особенно с точки зрения парадигмы «тонкий контроллер, толстая модель».

Иными словами, я считаю, что надо написать такой метод paginateCount, который будет подсчитывать записи в таблице без присоединения зависимых моделей. Сделать это можно жестко задавая параметр $recursive при вызове Model::find(‘count’…). Получится примерно такой код:

function paginateCount($conditions, $recursive, $extra)
{
    return $this->find('count',
        array(
            'conditions'=>$conditions,
            'recursive'=>-1
        )
    );
}

Теперь при вызове COUNT(*) не будет совсем никаких JOIN’ов, несмотря ни на какие отношения.

Я довольно долго пользовался этим вариантом метода и быль вполне им доволен. Но совсем недавно возникла необходимость все-таки в полном подсчете записей — из-за условия отбора по полю присоединенной модели. Совсем убирать этот метод мне не хотелось и я решил просто добавить возможность указания — надо ли использовать для подсчета запрос с присоединенными моделями или можно обойтись подсчетом записей только в одной. Если конкретнее, то для frontend метода index использую «быстрый» метод подсчета, а в админской части есть более сложные фильтры, требующие использования «медленного» метода. Чтобы указать необходимость использования «медленного» метода, с использованием присоединенных моделей, используется дополнительный ключ в массиве Controller::paginate. Что я, зря, чтоль столько букв про $extra написал? :-) Теперь если задан сложный фильтр по записям, кроме условий в Controller::paginate['conditions'], добавляю ключ Controller::paginate['count_recursive']=1. А метод стал выглядить так:

function paginateCount($conditions, $recursive, $extra)
{
    if (@$extra['count_recursive']) {
        unset($extra['count_recursive']);
    } else {
        $recursive=-1;
    }
 
    return $this->find('count', 
        array_merge(
            array(
                'conditions'=>$conditions,
                'recursive'=>$recursive),
                $extra
            )
        );
}

Получилось, на мой взгляд вполне неплохо.

Model::paginate

После доработки подсчета я решил посмотреть, что можно сделать с самим запросом на выборку. По сути, find(‘all’, …) он и есть find(‘all’, …) чего там еще с ним сделаешь? Тем не менее, из метода контроллера Controller::paginate(), одноименный метод модели Model::paginate() вызывается с множеством параметров.

function paginate($conditions, $fields, $order, $limit, $page = 1, $recursive = null, $extra = array())

Для простых запросов тут не стоило бы и напрягаться. Зато для сложных запросов, которые CakePHP не может выполнить сам, или выполняет неоптимально, вызов этого метода — золотое дно. Ведь здесь можно манипулировать результирующими данными.

В качестве примера, простая ситуация с цепочкой из трех моделей. Таблица с продуктами, у которых есть много цен (розничная, опт1, и т.д.) в разных валютах (их всего три, так получилось). Для работы только с розничными ценами мы перепривязали с помощью unbindModel() и bindModel() модель с ценами как hasOne с условием Price.price_type=’retail’. Но цепочка из трех моделей осталась:

• модель Product владеет ценой (hasOne) Price;
• Price принадлежит валюте (belongsTo) Currency

Обычный Model::find(‘all’…) поступит просто. Выберет все записи Product-JOIN-Price, а потом для каждого элемента массива выберет Currency. С учетом того, что в самом худшем варианте, на странице будут цены в трех валютах, двадцать запросов ‘SELECT Price … ‘ все равно выглядят удручающе. В похожей ситуации я поступил так:

• С помощью recursive при вызове Model::find(‘all’,…) ограничил выборку только связью Product-Price
• Используя Set::classicExtract получил массив id нужных валют. Можно было и с помощью SQL запроса SELECT DISTINCT это сделать, но Set::classicExtract мне ближе ;-)
• Выбрал нужные вылюты из модели Currency
• Добавил в массив, полученный в первом пункте выбранные валюты в соответствии с Price.currency_id

Получилось всего три запроса, включая запрос на подсчет!

Возможность оптимизации менее сложных запросов при вызове Controller::paginate() тоже есть.

Когда я сделал свой метод Model::paginateCount() для общей и админской части, обратил внимание, что возможен вариант, когда в админской части заданы такие условия выборки, под которые не попадает ни одной записи. Например, в указанном разделе автор не опубликовал ни одной записи. В этом случае возвращается, как нетрудно догадаться, пустой массив. Поскольку меня уже было не остановить :-) , я задался вопросом — а если нет ни одной записи, и paginateCount() это уже определил, то зачем вообще выполнять запрос к БД на выборку? Можно же просто вернуть пустой массив! Так и поступил.

В модель добавил переменную, в которую Model::paginateCount() записывал полученное количество записей.

private $_lastPaginationCountResult = 0;
 
function paginateCount($conditions, $recursive, $extra)
{
    if (@$extra['count_recursive']) {
        unset($extra['count_recursive']);
    } else {
        $recursive=-1;
    }
 
    $this->_lastPaginationCountResult = $this->find('count', 
        array_merge(
            array(
                'conditions'=>$conditions,
                'recursive'=>$recursive),
                $extra
            )
        );
 
    return $this->_lastPaginationCountResult;
}

И написал маленький метод Model::paginate(). Мною собственноручно написана только одна строка, проверка переменной с результатами paginateCount(), которая была вызвана до того. Весь остальной код просто скопировал из соответствующего метода Controller::paginate().

function paginate($conditions, $fields, $order, $limit, $page = 1, $recursive = null, $extra = array()) {
 
    if ($this->_lastPaginationCountResult === 0) return array();
 
    $parameters = compact('conditions', 'fields', 'order', 'limit', 'page');
 
    if ($recursive != $this->recursive) {
        $parameters['recursive'] = $recursive;
    }
 
    if (array_key_exists('type', $extra)) {
        $type = $extra['type'];
        unset($extra['type']);
    }
    else $type='all';
 
    return $this->find($type, array_merge($parameters, $extra));
}

Кстати, обратите внимание, на параметр type, это не я придумал, это в оригинале так было. Он позволяет вместо find(‘all’,…) использовать для выборки любой другой тип запроса. Даже самостоятельно определенный, например, find(‘recent’,…), если, конечно, поддержку этого метода кто-нибудь заранее напишет ;-)