Я использую переменную SESSION, чтобы установить предварительно выделенный идентификатор записи из Postgres (получая последовательность идентификаторов записи), используя DB PEAR nextId () . Я установил идентификатор I в переменную сеанса из-за проблем с областями видимости в унаследованном коде, с которым я работаю. После того, как произойдет INSERT, я использую unset () , чтобы удалить переменную SESSION (для очистки идентификатора используемой записи). В сеансе также содержится больше информации, которая остается неизменной, это просто удаляемый элемент next_id.
Псевдокод:
// Get the next Id and set to SESSION
$_SESSION['next_id'] = $db->nextId();
... more code here
// After insert
unset($_SESSION['next_id']);
У меня такой вопрос, может ли нажатие на кнопку возврата в браузере каким-либо образом сбросить переменную SESSION $_SESSION['next_id']? Может быть, из-за этого NULL? Как CACHE обрабатывает SESSION после того, как элемент был удален, но пользователь вернулся в предыдущее состояние?
EDIT:
причина этого вопроса в том, что производственный код произвольно (любым пользователем) пытается ВСТАВИТЬ с ИДЕНТИФИКАТОРОМ записи NULL (который является next_id из SESSION). Просто попытка отладки процесса, поскольку код очень минимален, проверен моими коллегами и только что поставил нас в тупик ???
РЕДАКТИРОВАТЬ 2:
Ух ты, я думаю, есть проблема с тем, как я использую переменную SESSION.
Хорошо, я объясню столько, сколько я могу, почему я выбрал этот метод.
Сначала код находится в процессе переписывания из PHP 4, но текущей рабочей версией в основном является PHP 4 с большим количеством недавно добавленного кода модуля в PHP 5.
Причина, по которой я выбрал переменную SESSION, заключается в том, что проблема с областью видимости должна быть жестко задана на нескольких сотнях страниц устаревшего кода или на одной странице и преобразовать значение в SESSION, к которому имеют доступ все страницы. (ну мой начальник, который платит мне зарплату, как вариант, который я выбрал).
Первоначальная проблема заключается в том, что они (мой начальник) хотели показать идентификатор конечному пользователю до вставки информации. Следовательно, PEAR DB вызывает nextId (). Мы используем PostgreSQL, и я использую последовательность идентификаторов записей, чтобы гарантировать, что следующий идентификатор будет уникальным и будет выделен только конечному пользователю (без дубликатов, поскольку Postgres обрабатывает блокировку этого в последовательности).
Таким образом, конечный пользователь также может перемещаться по нескольким страницам во время процесса, это также является другой проблемой.
Теперь использование SESSION и получение следующего идентификатора с некоторой проверкой и проверками составляет около 50 строк кода для всего процесса вместо тысяч строк кода, которые были бы написаны для правильной работы.
Опять же, НЕ МОЙ КОД, во-первых, просто лучшее решение с наименьшими затратами.
Если у вас есть другое, лучшее, лучшее, более простое и дешевое решение, не стесняйтесь отправлять. Но если вы не согласитесь с моим решением о кодировании, пожалуйста, оплатите мои счета, и я полностью согласен с более строгим стандартом кодирования, практикой, решением.