← Назад к заметкам

Заметки

Как вывести SQL запроса ORM для отладки

Как вывести SQL запроса ORM в коробке: Query, getQuery, параметры, php_command_line и аккуратная отладка.

В заметке разбираем тему: Как вывести SQL запроса ORM для отладки. Главное — не переносить решение вслепую с другого портала, а проверить контекст коробки, права, версию модулей и фактические данные.

Задача

Как вывести SQL запроса ORM в коробке: Query, getQuery, параметры, php_command_line и аккуратная отладка.

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

Ключевые вещи в этой теме: Query, getQuery, SQL. Именно их стоит проверить первыми, прежде чем менять код.

Как это устроено

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

Если код выполняется внутри портала, у него есть контекст Битрикса: подключённые модули, текущий пользователь, права, кеш и события. В CLI, cron или внешнем скрипте часть этого контекста нужно создать вручную.

Для CRM, Диска, календаря, пользовательских полей и модулей лучше начинать со штатных API. Прямые SQL-запросы и правка файлов ядра подходят только как крайняя диагностика, а не как основной способ доработки.

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

Рабочий подход

Сначала зафиксируйте контекст, потом проверяйте API и только после этого меняйте данные.

  • Проверьте, где выполняется код: веб, CLI, cron, агент, обработчик события или iframe приложения.
  • Подключите нужные модули явно и обработайте ситуацию, когда модуль недоступен.
  • Сначала выведите тестовые данные или SQL, затем выполняйте изменение.
  • Для боевого портала добавьте логирование результата и ошибок.

Частые ошибки

Большинство проблем появляется из-за неверного контекста или обхода штатной логики.

  • Код проверяют только под администратором, а потом он не работает у сотрудников.
  • Доработку кладут в /bitrix или в перегруженный init.php вместо /local или модуля.
  • Ошибки не логируются, поэтому после cron, агента или события непонятно, запускался ли код вообще.
  • Данные меняют напрямую, минуя операции, события, права, индексы и кеш.

Минимальный пример

Пример показывает базовую форму. ID, пути, названия модулей и поля нужно заменить под свой портал.

<?php

$query = \Bitrix\Crm\DealTable::query()
    ->setSelect(['ID', 'TITLE'])
    ->setFilter(['>ID' => 100])
    ->setLimit(10);

$sql = $query->getQuery();

file_put_contents(
    $_SERVER['DOCUMENT_ROOT'] . '/local/logs/orm_sql.log',
    $sql . PHP_EOL,
    FILE_APPEND
);