Вопрос

Одна вещь, которая всегда была проблемой, — это регистрировать ошибки SQL (JDBC), когда у вас есть ReadedStatement вместо самого запроса.

Вы всегда получаете сообщения типа:

2008-10-20 09:19:48,114 ERROR LoggingQueueConsumer-52 [Logger.error:168] Error 
executing SQL: [INSERT INTO private_rooms_bans (room_id, name, user_id, msisdn, 
nickname) VALUES (?, ?, ?, ?, ?) ON DUPLICATE KEY UPDATE room_id = ?, name = ?, 
user_id = ?, msisdn = ?, nickname = ?]

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

Отредактировано после нескольких ответов:

Предоставленные библиотеки подходят для протоколирования операторов отладки, что, несомненно, полезно.Однако я ищу способ взять сам ReadedStatement (а не какой-то подкласс) и регистрировать его оператор SQL при возникновении ошибки.Мне бы не хотелось развертывать производственное приложение с альтернативной реализацией ReadedStatement.

Я думаю, мне нужен служебный класс, а не специализация ReadedStatement.

Спасибо!

Это было полезно?

Решение

Я пытался log4jdbc и это помогло мне.

ПРИМЕЧАНИЕ БЕЗОПАСНОСТИ:По состоянию на август 2011 г. зарегистрированные результаты подготовленного оператора log4jdbc НЕ БЕЗОПАСНЫ для выполнения.Их можно использовать для анализа, но НИКОГДА не следует возвращать в СУБД.

Пример журнала, созданного logjdbc:

2010/08/12 16:30:56 jdbc.sqlonly org.apache.commons.dbcp.delegatingpreparedStatement.executeUpdate (делегированиеВставьте в A_TABLE (ID_FILE, CODE1, ID_G, ID_ESSECENTE, REF, Имя, Бар, Drink_ID, сумма, описание, статус, code2, reject_descr, id_cust_rej) значения (2, '123', 1, '2', 'aa', 'Awe', Null, '0123', 4317.95, 'rccc', '0', null, null, null)

Библиотеку очень легко настроить:


Моя конфигурация с HSQLDB :

jdbc.url=jdbc:log4jdbc:hsqldb:mem:sample

С Оракул :

jdbc.url=jdbc:log4jdbc:oracle:thin:@mybdd:1521:smt
jdbc.driverClass=net.sf.log4jdbc.DriverSpy

logback.xml:

<logger name="jdbc.sqlonly" level="DEBUG"/>

Жаль, что его не было в репозитории maven, но все равно полезно.
Из того, что я пробовал, если вы установите

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

Другие советы

Это очень зависит от базы данных.Например, я понимаю, что некоторые драйверы JDBC (например.sybase, возможно, ms-sql) обрабатывают подготовленные операторы, создавая временную хранимую процедуру на сервере, а затем вызывая эту процедуру с предоставленными аргументами.Таким образом, полный SQL никогда не передается от клиента.

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

Я думаю, вам, возможно, просто придется стиснуть зубы и написать свой собственный класс, который интерполирует аргументы в SQL-заполнитель.Это будет неудобно, потому что вы не можете запросить у ReadreadedStatement установленные параметры, поэтому вам придется запомнить их во вспомогательном объекте, прежде чем передавать их оператору.

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

Использовать P6Spy:Это Oracle, Mysql, JNDI, JMX, Весна и Мавен дружелюбно.Широкие возможности настройки.Простая и низкая интеграция может распечатать трассировки стека.Можно только распечатать тяжелые звонки - на основе временного порога.

  1. Если вы используете MySQL, используйте метод ReadedStatement.toString() MySQL Connector. включает связанные параметры.Хотя сторонние пулы соединений могут нарушить это.

  2. Подкласс ReadedStatement для создания строки запроса по мере добавления параметров.Невозможно извлечь SQL-код из ReadedStatement, поскольку он использует скомпилированную двоичную форму.

Запись LoggedPreparedStatement выглядит многообещающе, хотя я не пробовал.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top