Alteração na classe AbstractVersionatedEntity

[evertonbraga]

Acredito que seria interessante adicionar um atributo(String username) para gravar o nome do usuário que adicionou/alterou o registro para auditoria do sistema.

[rmpestano]

Everton,

a classe AbstractVersionatedEntity é para controle de versão da entidade(sim faltou a descrição na classe ;) ) e possibilitar lock otimista em uma transação, veja [1]

nós temos que pensar uma maneira e onde incluir dados para controle, no momento eu tenho algumas idéias mas estou aberto a sugestões:

1 - criar uma nova classe abstrata na hierarquia que estenda a AbstractVersionatedEntity.

vantagens: eu posso escolher em ter somente controle de versão ou ter dados de auditoria
desvantagens: eu vou ter sempre controle de versão pois to estendendo de AbstractVersionatedEntity

2 - criar duas classes abstratas uma extendendo de AbstractVersionatedEntity e outra de AbstractBaseEntity
vantagens: posso escolher ter apenas auditoria, apenas controle de versão ou ambos
desvantagens: a hierarquia de classes de modelo fica mais complexa com muitas classes abstratas, o usuario pode não saber o que deve estender.

3 - criar uma interface UserAudit obrigando a entidade que implementar a interface implementar os métodos get/setUserControl
vantagens: eu decido quando quero auditar a entidade sem a necessidade de mexer na hierarquia das classes de modelo(sem extender nada);
desvantagens: eu tenho que adicionar o campo @Embedable UserControl usercontrol e implementar os metodos get/setUserControl

Outra coisa que temos que ver é os dados que irão ser auditados, talvez o username não seja o ideial, acredito que o codigo do usuário sejá mais interessante caso seja necessário buscar mais informações do usuário posteriormente.

Outro aspecto importante em auditoria é saber o que o usuário alterou e para saber isso precisamos no minimo de 3 colunas na entidade 'campoAlterado', 'valor antigo', 'novo valor'

a Classe UserControl teria os seguintes atributos(aberto p/ discussão)

Object userId; //pode ser String ou Long, talvez deixe como String e quem usar Long como id de usuário pode fazer um toString na hora de preencher os dados de controle
String field ;//campo alterado
String oldValue;
String newValue;
Date changeDate; //data da alteração

Outro problema é de onde pegar esses dados de controle e quem vai setar esses valores.

quem vai setar esses dados: eu acredito que um Interceptor do CDI seja a maneira mais transparente e menos "intrusiva" de fazer isso, eu usaria o interceptor na service da entidade que eu gostaria de auditar ou tentar usar um Decorator do CDI.

de onde pegar os dados de controle:
1 - podemos pegar da Sessão
vantagens simplicidade
desvantagens deve ser garantido que os dados de controle estarão na Sessão, é inseguro usar o mapa de sessão
2 - podemos usar @Inject UserControl userControl;
vantagems: abordagem mais segura, type safe e pode ser usada em outras ocasiões
desvantagens: é necessário que exista um método produtor de UserControl
@produces @SessionScoped
public UserControl getUserControl(){
return dadosDeControleDoUsuarioLogado;
}

idéias/sugestões são bem vindas, eu to pensando em usar a interface para auditoria.

[1] http://www.objectdb.com/java/jpa/persistence/lock

[evertonbraga]

Rafael,

Estava pensando de uma forma bem simples de apenas controlar na própria entidade, onde para cada registro na base dados eu gravaria os dados(createDate, updateDate e username) para controle das alterações.

Mas pensando em fazer um sistema de auditoria mesmo, acredito que a terceira ideia utilizando interface para auditoria seria a melhor opção para este caso.