PHP: полный мануал с примерами, функциями и ООП

PECL CUBRID >= 8.3.1; поведение PHP7-порта 11.2.0.0002 явно отделено от замысла persistent API. · cubrid

cubrid_pconnect(string $host, int $port, string $dbname, string $userid = ?, string $passwd = ?): resource|false

Подключить запрос каталога через документированный persistent API и отдельно проверить фактический срок жизни подключения.

Результат: Ресурс соединения при успехе; false при отказе. Предупреждение и код нужно сохранить сразу. Успешный ресурс не доказывает ни повторное использование прежнего канала, ни права на конкретную таблицу.

При отказе сразу сохраните cubrid_error_code(), cubrid_error_code_facility() и cubrid_error_msg(), пока следующий вызов не изменил диагностику. Полный проект использует c173Capture для перехвата предупреждения и сохранения признаков отказа. Проверяйте результат через === false: пустой набор строк и число 0 сами по себе не означают ошибку.

Доступна с PECL CUBRID 8.3.1. Три первых аргумента обязательны; у двух последних PHP Manual показывает необязательность без универсального значения по умолчанию. Для воспроизводимого приложения задавайте все пять. Не переносите дополнительные аргументы cubrid_connect в публичный контракт pconnect только потому, что одна реализация делит внутренний обработчик.

Минимальная запись

$db = cubrid_pconnect($host, $port, $database, $user, $password);
if ($db === false) { throw new RuntimeException('Подключение не создано'); }

Соединение позволяет отправлять SQL, но не содержит автоматически полученных товаров. Следующий шаг — ограниченный SELECT. Пароль не следует печатать вместе с URL при диагностике.

Применение 1: обновляемая карточка товара

$request = cubrid_execute($db, 'SELECT sku,qty FROM stock WHERE id=42 LIMIT 1');
if ($request === false) { throw new RuntimeException('Карточка не прочитана'); }
try { $row = cubrid_fetch_assoc($request); }
finally { cubrid_close_prepare($request); }

Два HTTP-открытия каталога показывают остаток5, затем7 после отдельного commit поставки. Читатель каждый раз получает нужную строку SQL; сохранённый ресурс не является кэшем ответа SELECT.

Применение 2: отдельная транзакция каждого запроса

if (!cubrid_set_autocommit($db, false)) { throw new RuntimeException('Режим не задан'); }
try {
    // Пробный расчёт/резерв внутри одного HTTP-запроса.
} finally {
    cubrid_rollback($db);
}

Этот порядок применим и к URL-варианту в проекте отмены резерва. Если операция должна сохраниться, успешная ветка явно вызывает commit, а ошибочная — rollback. Сохранённые session-параметры, уровни изоляции, временные состояния и открытые запросы нельзя считать пользовательским хранилищем.

PHP Manual описывает постоянный канал: повторный вызов с тем же адресом базы и пользователем ищет открытое соединение, а завершение запроса и close/disconnect не должны закрывать такой канал. Это документированный замысел API, а не подтверждённая оптимизация данного профиля. В PHP7-исходнике cubrid 11.2.0.0002 cache lookup выполняется только при !persistent, pconnect-ресурс попадает в regular_list, а его деструктор вызывает cci_disconnect. В отдельных HTTP-запросах одного worker SQL marker не сохранился, ручной режим снова стал autocommit=true, незавершённый резерв был отменён. В этой версии нельзя обещать PHP persistent cache на основании названия функции. Мы не измеряли глобальный пул CCI/CAS и не выдаём эти наблюдения за поведение всех версий расширения.

Даже корректно реализованный persistent cache ограничен worker-процессом: другой процесс не обязан выдать тот же канал. Обычный CLI-запуск завершается целиком, а однажды выданный DB-канал нельзя закрепить за конкретным браузером. Постоянные каналы расходуют серверные подключения; их число зависит от числа workers и комбинаций реквизитов. Для решения о производительности нужна отдельная нагрузочная проверка, которой эти учебные GET не являются. При отказе сначала проверяют адрес, порт, доступность broker и учётные данные, затем SQL-права; диагностика подключения объясняет это отдельно.

• PHP Manual: cubrid_pconnect
• CUBRID 11.3: типы данных
• CUBRID 11.3: CCI
• Исходник native-драйвера

PECL CUBRID >= 8.3.1; поведение PHP7-порта 11.2.0.0002 явно отделено от замысла persistent API. · cubrid

cubrid_pconnect_with_url(string $conn_url, string $userid = ?, string $passwd = ?): resource|false

Задать persistent-подключение строкой конфигурации и ограничить ожидание входа, сохранив пароль отдельным аргументом.

Результат: Ресурс соединения либо false при отказе. URL не превращает подключение в веб-запрос: это строка параметров native CCI.

При отказе сразу сохраните cubrid_error_code(), cubrid_error_code_facility() и cubrid_error_msg(), пока следующий вызов не изменил диагностику. Полный проект использует c173Capture для перехвата предупреждения и сохранения признаков отказа. Проверяйте результат через === false: пустой набор строк и число 0 сами по себе не означают ошибку.

PECL CUBRID >=8.3.1. На странице PHP Manual сокращённая грамматика пропускает порт в одной строке, но примеры и CCI используют host:port:database. В этой главе показана рабочая полная форма. Сама возможность failover не означает, что прикладную транзакцию можно продолжить без проверки после смены сервера.

Минимальная запись

$url = 'CUBRID:127.0.0.1:33000:shop:::?login_timeout=3000';
$db = cubrid_pconnect_with_url($url, $user, $password);
if ($db === false) { throw new RuntimeException('Вход не выполнен'); }

В старом примере Manual встречается опечатка althost; в таблице используется имя alhosts из описания и CCI. В этом пакете не поднимаются резервные серверы и не исполняется failover. Реально проверенные временные ограничения запросов находятся в главе о настройках и сроках запросов.

Применение 1: резерв без утечки пароля в URL

$url = 'CUBRID:127.0.0.1:33000:shop:::?login_timeout=3000';
$db = cubrid_pconnect_with_url($url, $user, $password);
// $password может содержать ?: — они не встроены в строку URL.
if ($db === false) { throw new RuntimeException('Нет соединения для резерва'); }
cubrid_set_autocommit($db, false);

Резерв с двумя реальными HTTP-запросами демонстрирует URL-вызов, режим на входе и отмену неподтверждённых данных. Встраивать ?: в пароль внутри URL нельзя: это структурные разделители. Удалять лишние на вид двоеточия из пустых полей тоже нельзя.

Применение 2: один адрес конфигурации для каталога

$catalogUrl = 'CUBRID:127.0.0.1:33000:shop:::?login_timeout=3000&query_timeout=5000';
$catalogDb = cubrid_pconnect_with_url($catalogUrl, $user, $password);
if ($catalogDb === false) { throw new RuntimeException('Каталог недоступен'); }
// Затем SELECT только необходимых полей и явное завершение транзакции.

Так можно заменить способ задания адреса в каталоге товара, сохранив SQL-проекцию и явные границы. Код фрагмента объясняет параметры; проверенный полный URL-проект выше использует только login_timeout. Само добавление URL не обеспечивает повторное использование соединения.

PHP Manual описывает постоянный канал: повторный вызов с тем же адресом базы и пользователем ищет открытое соединение, а завершение запроса и close/disconnect не должны закрывать такой канал. Это документированный замысел API, а не подтверждённая оптимизация данного профиля. В PHP7-исходнике cubrid 11.2.0.0002 cache lookup выполняется только при !persistent, pconnect-ресурс попадает в regular_list, а его деструктор вызывает cci_disconnect. В отдельных HTTP-запросах одного worker SQL marker не сохранился, ручной режим снова стал autocommit=true, незавершённый резерв был отменён. В этой версии нельзя обещать PHP persistent cache на основании названия функции. Мы не измеряли глобальный пул CCI/CAS и не выдаём эти наблюдения за поведение всех версий расширения.

Никогда не принимайте готовый connection URL от посетителя. Конфигурация задаёт сервер назначения и реквизиты; доступ к конкретному SKU проверяется отдельно. Таймауты входа, запроса и ожидания блокировки — разные ограничения.

• PHP Manual: cubrid_pconnect_with_url
• CUBRID 11.3: типы данных
• CUBRID 11.3: CCI
• Исходник native-драйвера

PECL CUBRID >= 8.3.1; поведение PHP7-порта 11.2.0.0002 явно отделено от замысла persistent API. · cubrid

cubrid_close(resource $conn_identifier = ?): bool

Закончить работу владельца соединения после явного решения о данных и освобождения запросов.

Результат: true при успешном закрытии, false при отказе. После успеха ресурс не используется повторно. Необязательный аргумент не означает, что безопасно закрывать любой последний канал из глубоко вложенной функции.

При отказе сразу сохраните cubrid_error_code(), cubrid_error_code_facility() и cubrid_error_msg(), пока следующий вызов не изменил диагностику. Полный проект использует c173Capture для перехвата предупреждения и сохранения признаков отказа. Проверяйте результат через === false: пустой набор строк и число 0 сами по себе не означают ошибку.

PECL CUBRID >=8.3.1. Manual описывает завершение текущей транзакции, закрытие connection handle, отключение сервера и оставшихся request handles; функция похожа на cubrid_disconnect. Формулировка «завершение» не заменяет ваше решение commit или rollback. Перед close явно закончите транзакцию с нужным смыслом.

Минимальная запись

if (!cubrid_commit($db)) { throw new RuntimeException('Данные не подтверждены'); }
if (!cubrid_close($db)) { throw new RuntimeException('Соединение не закрыто'); }
$db = null;

Применение 1: подтвердить поставку и проверить новое чтение

// UPDATE уже проверен, request освобождён.
cubrid_commit($db);
cubrid_close($db);
$db = null;
$fresh = cubrid_connect($host, $port, $database, $user, $password, true);
// Новый SELECT проверяет сохранённое количество.

Проект со сроками ресурсов подтверждает7, закрывает соединение и читает7 заново. Это проверка сохранённых данных, а не повторный вызов по недействительному ресурсу.

Применение 2: завершить отменённую операцию

try {
    // Операция завершилась бизнес-отказом; её запрос уже освобождён.
    if (!cubrid_rollback($db)) { throw new RuntimeException('Отмена не подтверждена'); }
} finally {
    cubrid_close($db);
    $db = null;
}

Отмена резерва в HTTP-проекте учит явному rollback; такой шаблон закрытия нужен владельцу обычного короткого соединения. HTTP-наблюдение специально не закрывает pconnect в первом запросе, чтобы исследовать request boundary; не переносите это исключение в произвольную бизнес-операцию.

Есть важная версия границы: страницы pconnect обещают, что close/disconnect не закрывают persistent link. В проверенном PHP7-порте close действительно проходит через zend_list_close, а persistent-деструктор вызывает cci_disconnect; реальная подготовка получила true и недействительный ресурс. Поэтому проект не полагается на историческое обещание сохранения pconnect. Подробность — контракт pconnect и фактический профиль.

Close соединения и close_prepare запроса решают разные задачи. Библиотечная функция, которая получила чужой $db ради чтения, обычно освобождает свой запрос и возвращает строку, не закрывая канал владельца. При нескольких соединениях используйте явные переменные и закрывайте каждое отдельно; «последнее» может оказаться уже другим.

• PHP Manual: cubrid_close
• CUBRID 11.3: типы данных
• CUBRID 11.3: CCI
• Исходник native-драйвера

PECL CUBRID >= 8.3.0; поведение PHP7-порта 11.2.0.0002 явно отделено от замысла persistent API. · cubrid

cubrid_close_prepare(resource $req_identifier): bool

Освободить закончившийся request handle: подготовленный запрос или результат обычного execute.

Результат: PHP Manual описывает true при успехе. Alias выполняет то же закрытие, что close_request; недопустимый или уже закрытый ресурс находится вне поддержанного контракта. Проверенный исходник не содержит надёжной проверки такого аргумента перед обращением к ресурсу, поэтому безопасный false на нём не обещается. Передавайте только действующий request, принадлежащий вашему коду, и не проверяйте закрытие повторным вызовом.

При отказе сразу сохраните cubrid_error_code(), cubrid_error_code_facility() и cubrid_error_msg(), пока следующий вызов не изменил диагностику. Полный проект использует c173Capture для перехвата предупреждения и сохранения признаков отказа. Проверяйте результат через === false: пустой набор строк и число 0 сами по себе не означают ошибку.

PECL CUBRID >=8.3.0. Это alias cubrid_close_request: другое имя того же действия, не особая разновидность commit. Освобождается связанная с запросом память и request handle. Параметры подготовленного запроса после этого не переиспользуются; для повторного выполнения держат его открытым до конца серии или создают новый.

Минимальная запись

if (!cubrid_close_prepare($request)) { throw new RuntimeException('Запрос не освобождён'); }
$request = null;

Применение 1: закончить подготовленное изменение

$request = cubrid_prepare($db, 'UPDATE stock SET qty=? WHERE id=42');
if ($request === false) { throw new RuntimeException('Нет запроса'); }
try {
    if (!cubrid_bind($request, 1, 4, 'number') || !cubrid_execute($request)) {
        throw new RuntimeException('Изменение не выполнено');
    }
} finally { cubrid_close_prepare($request); $request = null; }
// commit/rollback ещё требуется отдельно.

Пробное изменение остатка оставляет4 после закрытия запроса и возвращает5 только после rollback. Полученный ранее PHP-массив можно читать после close_prepare: это уже данные приложения, а не живой курсор.

Применение 2: закончить весь список результатов

try {
    // Читать текущий набор, затем cubrid_next_result($request).
    // Сохранить только необходимые массивы строк/итоги.
} finally {
    cubrid_close_prepare($request);
    $request = null;
}

В составном отчёте request остаётся один, хотя внутри него меняются три набора. Освободить его после первого набора означало бы потерять доступ к следующим. В HTTP-каталоге каждый короткий SELECT освобождается в том запросе HTTP, где был открыт.

Освобождение request не гарантирует освобождения всех блокировок транзакции и не заканчивает канал к серверу. Для LOB-ресурсов, выданных запросом, дополнительно действуют ограничения времени жизни порционного LOB-чтения. Не сохраняйте request resource для следующего HTTP-запроса и не передавайте его в JSON.

• PHP Manual: cubrid_close_prepare
• CUBRID 11.3: типы данных
• CUBRID 11.3: CCI
• Исходник native-драйвера

PECL CUBRID >= 8.4.0; поведение PHP7-порта 11.2.0.0002 явно отделено от замысла persistent API. · cubrid

cubrid_next_result(resource $result): bool

Переключить один request handle на результат следующей SQL-команды заранее составленного пакета.

Результат: true — следующий результат доступен; false — переход не состоялся. PHP Manual называет false отказом; pinned source также возвращает false при обычном конце CAS_ER_NO_MORE_RESULT_SET, не устанавливая ошибку. Поэтому сразу сохраняют код, facility и предупреждение, чтобы отличить конец от ошибки.

При отказе сразу сохраните cubrid_error_code(), cubrid_error_code_facility() и cubrid_error_msg(), пока следующий вызов не изменил диагностику. Полный проект использует c173Capture для перехвата предупреждения и сохранения признаков отказа. Проверяйте результат через === false: пустой набор строк и число 0 сами по себе не означают ошибку.

PECL CUBRID >=8.4.0. Функция меняет текущие столбцы, число строк и тип команды внутри существующего запроса; она не возвращает новый массив строк. fetch читает строки текущего SELECT; affected_rows описывает INSERT/UPDATE/DELETE. Не вызывайте fetch как универсальное чтение любой SQL-команды.

Минимальная запись

$r = cubrid_execute($db, 'SELECT 5 AS qty; SELECT 7 AS total', CUBRID_EXEC_QUERY_ALL);
if ($r === false) { throw new RuntimeException('Нет пакета'); }
$first = cubrid_fetch_assoc($r);
$next = cubrid_next_result($r);
$code = cubrid_error_code(); // Сразу, до следующего обращения к драйверу.
if ($next === true) { $second = cubrid_fetch_assoc($r); }
elseif ($code !== 0) { throw new RuntimeException('Следующий результат ошибочен'); }
cubrid_close_prepare($r);

Применение 1: каталог, пустая подборка и сводка

Полный составной отчёт получает две позиции, пустую подборку отрицательного остатка и итог7. Между результатами получается true/true, после третьего — false с чистой диагностикой. Пустой массив строк не является ошибкой и не завершает весь пакет.

// После чтения первого набора:
if (cubrid_next_result($r)) {
    $emptyRow = cubrid_fetch_assoc($r); // false: в этом SELECT нет строк.
    // Диагностика fetch и переход к третьему набору — отдельные действия.
}

Применение 2: квитанция изменения и итог

$sql = 'UPDATE stock SET qty=qty+1 WHERE id=42; SELECT qty FROM stock WHERE id=42';
$r = cubrid_execute($db, $sql, CUBRID_EXEC_QUERY_ALL);
if ($r === false) { throw new RuntimeException('Пакет изменения не выполнен'); }
$changed = cubrid_affected_rows($r);
if (cubrid_next_result($r) !== true) { throw new RuntimeException('Нет подтверждающей строки'); }
$row = cubrid_fetch_assoc($r);
// Проверить changed и row, дочитать переходы, закрыть request, затем commit/rollback.

В реальной подготовке проверен переход SELECT → пустой SELECT → UPDATE → сводка и rollback всего изменения. Короткий вариант выше показывает применение той же механики к квитанции; это не отдельный опубликованный самостоятельный проект. Правила разделения request и транзакции подробно видны в проекте закрытия ресурсов и главе о транзакциях.

QUERY_ALL не является защитой от SQL-инъекции и не превращает набор команд в независимые транзакции. Не собирайте такой SQL из произвольного ввода; значения пользовательского фильтра передаются через prepare/bind. Результаты имеют разные столбцы: нельзя заранее применить одну структуру строки ко всем. При ошибке позднего шага сохраняют диагностику и явно отменяют неподтверждённые изменения. Успешный первый SELECT ещё не подтверждает успех всего пакета.

• PHP Manual: cubrid_next_result
• CUBRID 11.3: типы данных
• CUBRID 11.3: CCI
• Исходник native-драйвера