Комментарии 6
А зачем лезть в сорцы? Почему не вызывать процедуры специально для этого предназначенного пакета
Единственный мной придуманный довод — отсутствие в коде строк
php
DBMS_APPLICATION_INFO
?Единственный мной придуманный довод — отсутствие в коде строк
$stmt = oci_parse ($conn, 'BEGIN dbms_application_info.set_action (:action); END;');
oci_bind_by_name ($stmt, ':action', $_REQUEST ['REQUEST_URI']);
oci_execute($stmt);
php
+2
Можно и так, но когда на площадке несколько сотен проектов, то залезть в сорцы php проще, чем заставить разработчиков пройтись по всем проектам и не забывать эти строки во всех следующих.
0
Ага, а потом вы пропатчите так еще пару-тройку расширений, и когда придет время их обновлять, будете снова руками все эти патчи накладывать. Это плохая практика имхо.
Нормальный способ — использовать во всех проектах общую прослойку для работы с базой и туда такие вещи добавлять.
Нормальный способ — использовать во всех проектах общую прослойку для работы с базой и туда такие вещи добавлять.
+1
Если я не ошибаюсь, один из основных плюсов OpenSource — возможность изменять его под свои задачи. Мы этот плюс используем в своей работе. Использовать общую прослойку для работы с базой или патчить используемые библиотеки — это вопрос скорее организационный, нежели технический.
0
Я согласен с Urevic изменения библиотек вообще последнее дело — если только ващи изменения не уйдут обратно в библиотеку.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Host и Request_Uri в списке сессий Oracle