Este artigo foi incrementado e expandido pela equipe InfoQ Brasil
Pouco antes de completar dois meses do lançamento do Hibernate 4.0, a comunidade JBoss anunciou a nova versão 4.1 do seu framework open source para mapeamento objeto/relacional (ORM). Embora menor, essa versão inclui correções e melhorias importantes, como a implementada no módulo de auditoria que facilita a comparação das mudanças de um entidade.
Manter os históricos das informações gravadas de um banco de dados é uma exigência comum em aplicações corporativas. Manter versões anteriores dos dados e suas estruturas pode ser uma solução para recuperar as modificações realizadas no sistema, ou mesmo atender um requisito de segurança: a auditoria dos dados. O objetivo é de que a qualquer momento seja possível ler o "backlog" (resumo histórico) e identificar todas as transições de uma tabela de banco de dados até o momento atual.
Esse tipo de requisito pode ser implementado internamente, com código feito pela própria equipe do projeto. Uma solução possível, por exemplo, seria criar uma tabela de histórico para manter todos os registros de modificações realizadas em tabelas que necessitam de auditoria. Portanto a tabela auditada mantém apenas o estado atual dos dados, enquanto a tabela de histórico mantém todos os estados intermediários com algum metadado complementar (ex: a data e o usuário que efetuou a modificação).
Esta estratégia requer ajustes em todo o código que manipula o banco de dados, de forma que a persistência seja realizada em duas etapas. A primeira é salvar o estado anterior dos dados na tabela de histórico e o segundo é realizar a persistência do estado atual, como o código fazia antes da auditoria. Isso também significa que todo código novo deve ser implementado em conformidade com este princípio, tornando essa solução extremamente intrusiva.
O Envers é um módulo do Hibernate que resolve esse problema de forma transparente. O principio de manter uma tabela de histórico para armazenar os estados intermediários das entidades ainda é o mesmo. A diferença é que toda a gestão do histórico é realizada pelo Envers, nos bastidores, sem a necessidade de escrever código complementar. O desenvolvedor utiliza apenas algumas anotações para habilitar o serviço de auditoria. O Envers funciona de maneira similar ao Subversion, aonde cada modificação gera uma nova revisão global no banco de dados.
O módulo disponibiliza uma API para consultas quer permite, por exemplo, consultar quais eram os dados de um entidade em uma determinada revisão. O Envers foi integrado ao Hibernate Core na versão 3.6, portanto as funcionalidades descritas até o momento já estavam disponíveis no Hibernate 4.0.
A novidade do Hibernate 4.1, relacionada ao Envers, é a capacidade de controlar modificações realizadas individualmente nas propriedades de uma entidade. Até a versão anterior, o Envers armazenava o histórico com o estado completo, com todas as propriedades, dos objetos. Dessa forma para identificar as diferenças entre as entidades, era necessário levar em consideração o estado completo das revisões em comparação. A partir de agora com o novo método hasChanged, da classe AuditProperty, o Envers permite a comparação de entidades em revisões diferentes levando em consideração uma propriedade.
Outras melhorias podem ser exploradas em detalhes nas notas da versão, por exemplo: suporte a multitenancy e a habilidade de customizar o mecanismo que sincroniza o estado da entidade (dirty handling).