ejemplos - Hacer un seguimiento de las propiedades modificadas en JPA
jpa ejemplos (1)
Tal vez puedas usar el oyente de evento de entidad al ras de Hibernate. Las propiedades sucias se calculan antes de la descarga. Puede almacenarlos en algún lugar de su base de datos.
Un código de ejemplo de uso de la característica de propiedades sucias de Hibernate que puede darte una idea.
Actualmente, estoy trabajando en un proyecto Java EE con algunos requisitos no triviales con respecto a la administración de la persistencia. Los cambios en las entidades por los usuarios primero deben aplicarse a una copia de trabajo antes de ser validados, después de lo cual se aplican a los "datos en vivo". Cualquier cambio en los datos en vivo también debe tener algún registro de ellos, para permitir la auditoría.
Las entidades se administran a través de JPA, y Hibernate se usará como proveedor. Eso es un hecho, así que no rehuimos las cosas específicas de Hibernate. Para el primer requisito, se usan dos unidades de persistencia. Uno asigna las entidades a las tablas de "datos en vivo" y el otro a las tablas de "copia de trabajo". Para el segundo requisito, vamos a utilizar Hibernate Envers, una buena opción para nuestro caso de uso.
Hasta aquí todo bien. Ahora, cuando los usuarios vean los datos en el front-end (basado en web), sería muy útil poder indicar qué campos se cambiaron en la copia de trabajo en comparación con los datos en vivo. Un color diferente sería suficiente. Para esto, necesitamos alguna forma de saber qué propiedades fueron alteradas. Mi pregunta es, ¿cuál sería una buena manera de hacerlo?
Usando la API de JavaBeans, un PropertyChangeListener podría ser suficiente para recibir notificaciones de cualquier cambio en una entidad de la copia de trabajo y mantener un conjunto de ellos. Pero el conjunto también debería persistir, ya que la aplicación podría reiniciarse y los cambios pueden durar mucho antes de que se validen y se apliquen a los datos en vivo. Y aplicar los cambios en los datos en vivo para obtener la copia de trabajo cada vez que se necesita no es factible (de ahí las dos unidades de persistencia). También podríamos comparar la copia de trabajo con los datos en vivo y encontrar campos que son diferentes. Algún código de introspección y reflexión sería suficiente, pero una vez más parece bastante intensivo en el procesamiento, sin mencionar que los datos en vivo tendrían que ser obtenidos. Tal vez me falta algo simple, o alguien sabe de una maravillosa función JPA / Hibernate que puedo usar. Incluso si no puedo evitar hacer (a) tablas de base de datos separadas para almacenar dicha información hasta que se aplique a los datos en vivo, algunas mejores prácticas o experiencias de la vida real con este escenario podrían ser muy útiles.
Me doy cuenta de que es una pregunta semiabierta, pero seguramente otras personas deben haber encontrado un requisito como este. Cualquier buena sugerencia es apreciada, y cualquier indicador a una solución ya hecha sería un buen candidato como respuesta aceptada.