No post anterior, eu tinha dito que faria um outro post apenas para dar ênfase nas consultas dos objetos marcados para serem auditados. Foi necessário concentrar esses assuntos em um post pois existem algumas particularidades que só as consultas com objetos auditáveis tem. Portanto, vamos a elas.
As consultas que são utilizadas pelo Envers são semelhantes ao modelo criteria, recurso nativo do Hibernate. O framework permite a consulta em duas dimensões: a primeira, horizontal, corresponde ao estado do banco de dados em uma dada revisão. A segunda, vertical, são as revisões na qual as entidades são modificadas.
A documentação afirma que a principal limitação, quando se trata de queries, são as consultas com relacionamento entre os objetos, recurso não suportado previamente pelo framework. Outro fator negativo é o fato das consultas aparentarem ser mais lentas que as consultas sobre os dados ditos “vivos”, ou melhor, os dados das entidades na qual o banco de dados foi projetado. Porém, é um recursos interessante, já que o framework da uma certa facilidade para a realização das consultas. Agora, nada impede de vc utilizar sql nativo para obter os dados de auditoria. Basta apenas compreender o schema e o mapeamento das chaves.
DETALHES DE USO
Os recursos disponíveis para a elaboração de consultas sobre os objetos de auditoria são simples de serem utilizados. A princípio é necessário obter um objeto chamado AuditReader de um EntityManager para poder realizar as consultas. A forma de obter tal objeto é descrita abaixo:
AuditReader reader = AuditReaderFactory.get(em);
Através desse objeto é possível utilizar os métodos de consulta existente na interface, ou melhor, utilizar os recursos, mesmo que capados, de criteria sobre os dados de auditoria, como abaixo:
List result = reader.createQuery()
.forRevisionsOfEntity(classe, false, false)
.add(AuditEntity.id().eq(id))
.getResultList();
Só uma observação; na documentação do produto, apesar de bem branda, está incompatível com os recursos disponíveis na versão 4 do hibernate. Pra quem ainda não sabe, o envers foi incorporado a arvore do hibernate para formar um produto apenas. Com isso, a documentação oficial está desatualizada com release principal do produto. Porém, as consultas são funcionais. Você pode utiliza-las como modelo para a elaboração de suas consultas.
DADOS DE AUDITORIA PERSONALIZADOS
Existe um recurso que foi muito útil para elaborar uma determinada consulta. Por padrão, as tabelas _AUD, geradas pelo framework, não armazena a data da alteração e nem mesmo quem alterou. Claro, isso, na maioria das vezes, fica por conta da implementação. Porém, caso seja necessário incluir dados amais sobre os objetos auditados é possível armazena-los em uma entidade sem a interferência no mapeamento do seu sistema. Isso é possível utilizando dois recursos: a anotação @RevisionEntity em conjunto com a interface RevisionListener. A classe que for anotada com @RevisionEntity deverá ter duas propriedades como equisito:
- um in ou long, anotado com @RevisionNumber, frequentemente um campo com valores gerados automaticamente
- um long ou um java.util.Date anotado com @RevisionTimeStamp, que seria mais um atributo preenchido pelo Envers.
Dica: caso não queira incluir os atributos de pré-requisito, utilize a anotação default: @DefaultRevisionEntity. Isso elimina completamente a necessidade de criação dos atributos de pré-requisito.
Após isso, é possível adicionar qualquer atributo a mais para suprir suas necessidades. Esses atributos serão persistidos como uma entidade normal. Tanto que, será necessário incluir a classes que armazenará esses atributos no persistence.xml.
O processo de criação aparentemente parece que está ok. Agora a pergunta é: Como esses dados serão armazenados? Isso é feito através de um listener que contem um método que é executado a cada modificação de uma entidade auditada. Portando, o trabalho de setar os valores fica por conta do programador. Abaixo está o listener utilizado como exemplo ilustrado na documentação oficial:
public class ExampleListener implements RevisionListener {
public void newRevision(Object revisionEntity) {
ExampleRevEntity exampleRevEntity = (ExampleRevEntity) revisionEntity;
Identity identity = (Identity) Component.getInstance("org.jboss.seam.security.identity");
exampleRevEntity.setUsername(identity.getUsername());
}
}
Fica ao critério do programador quais são os dados que serão armazenados e quando. Portanto, em um exemplo que fiz pra testar esses recurso inclui apenas o login do usuário informando quem foi o autor da alteração:
public class EnversRevisionListener implements RevisionListener {
@Override
public void newRevision(Object revisionEntity) {
Map<String,Object> session = ActionContext.getContext().getSession();
if(session != null) {
ApplicationUserElementSession userSession = (ApplicationUserElementSession) session.get(Constants.APPLICATION_USER_SESSION);
LoginRevEntity exampleRevEntity = (LoginRevEntity) revisionEntity;
exampleRevEntity.setTimestamp(new Date().getTime());
if(userSession != null) {
User userAutenticated = userSession.getUserAutenticate();
exampleRevEntity.setUsuario(userAutenticated.getLogin());
}
else {
exampleRevEntity.setUsuario("new_user");
}
}
}
}
A dica transmitida nesse post extrapolou um pouco. Foi além de consulta para auditoria personalizada. O que foi passado aqui foi apenas uma introdução, ou melhor, um subconjunto dos recursos que precisei para desenvolver meus métodos de auditoria. A documentação, apesar de desatualizada, é bem direta e simples de ser seguida. Porem, aconselho vc baixar o código do hibernate pelo github. No raiz vc vai encontrar o diretório hibernate-envers. É lá que está a nova versão do envers que é distribuída com o framework.
No Comments » 