¿Cómo se intercepta el SQL generado de Hibernate?

Para un sistema de seguridad que funciona como un hermano mayor (como un control de acceso obligatorio vigilado), tenemos que interceptar y manejar todas las declaraciones seleccionadas que hibernate está generando. Almacenamos el usuario, la marca de tiempo y la selección SQL en una base de datos para habilitar algunos perfiles con otras herramientas. La información permite determinar lo que un usuario intentó ver. Para las declaraciones seleccionadas, las propiedades preparadas son valiosas. Necesitamos la declaración SQL completa que incluya todos los parámetros.¿Cómo se intercepta el SQL generado de Hibernate?

¿Hay algún oyente o interceptor donde podamos unirnos y manejar todas estas cosas? El mayor problema pendiente hasta el momento es la recopilación de los parámetros de declaración.

Gracias

Fuente

2010-08-04 codevour

mkyong afirma que p6spy.jar mostrará las consultas de hibernación con valores de parámetros. Probablemente puedes probar esto http://www.mkyong.com/hibernate/how-to-display-hibernate-sql-parameter-values-solution/ – Naveen

Los valores reales de los parámetros pasan a estar disponibles (al menos que yo sepa), cuando el nivel de registro de org.hibernate package is set to DEBUG, and with the hibernate.show_sql property set. usa un JDBCAppender, si desea la salida del registrador en la base de datos.

Como alternativa, puede echar un vistazo a la log4jdbc project, que afirma lo siguiente:

En la salida conectado, por declaraciones preparadas, los argumentos se unen son inserta automáticamente en la salida de SQL . Esto mejora en gran medida la legibilidad y depuración de para muchos casos .

Si eso no es adecuado, podría investigar si P6Spy can be used in your situation. En el servidor WebLogic, la funcionalidad equivalente se logra a través del WebLogic JDBC Spy, que viene de fábrica con los controladores JDBC de WebLogic para ciertas bases de datos. Ambos escriben en System.out y no en una base de datos (a menos que esté equivocado), por lo que podría no ser tan útil.

Fuente

2010-08-04 07:50:57

Esto funciona muy bien, escribí mi propio apéndice para escribir las declaraciones en la base de datos. El único punto que se interpone en mi camino es cómo obtener el usuario correspondiente que disparó esta declaración. Esto es casi imposible de resolver. ¿Algunas ideas? – codevour

No estoy seguro de esto ya que no lo he probado. Básicamente, debe asignar el Usuario/Principal que está ejecutando la declaración SQL a los datos que se registran. En SLF4J/log4j/logback, esto se logra mediante MDC - Contexto de diagnóstico mapeado. Su cadena de patrones también deberá ser modificada para acomodar el principal. El artículo sobre cómo hacer que MDC funcione en logback podría ayudar - http://logback.qos.ch/manual/mdc.html Por cierto, no necesitaría MDC, si la cadena de patrones del apéndice se puede modificar para reflejar al usuario (si este es un caso de cadena de formato faltante). –

Muchas gracias, elegí el proyecto log4jdbc, ya que es el más activo, esto funcionó muy bien. Gracias de nuevo. – codevour

Puede utilizar Interceptor.prepareSQL() (3.1 +) para interceptar las declaraciones preparadas.

No creo que pueda obtener los parámetros reales sin bajar en la capa de abstracción. Una posible solución sería usar un controlador proxy JDBC (ver P6Spy).

Espero que ayude.

Fuente

2010-08-04 07:16:06 KeatsPeeks

Sí, conociendo esta interfaz, ¿dónde obtener los parámetros acotados? Por lo que sé, no hay forma de obtener los parámetros reales. – codevour

Para ser precisos, es 'Interceptor # onPrepareStatement (String sql)'. Pero esto le da acceso a la cadena SQL que se está preparando, no a la consulta * generated *. –

¿Cómo se intercepta el SQL generado de Hibernate?

Respuesta

Cuestiones relacionadas