Passa a existir a possibilidade de definir Triggers (estilo DB) para entidades Hibernate (tabelas).
- Não disparam quando são feitas alterações na BD (apenas via código)
- São apenas apanhados os eventos disparados por
- DIF DataSet API
- Hibernate Criteria API
- HQL
- SQL não dispara os triggers!
- Em situações em que várias aplicações estejam ligadas à mesma BD naturalmente que apenas dispara o trigger na instância de aplicação onde o método foi chamado
Estas limitações reduzem muito o âmbito onde esta feature pode ser utilizada.
Para um cenário alargado como os triggers a que estamos habituados teríamos que ter as seguintes regras:
- Não eram feitas ações de DML diretamente na BD
- Não são feitas ações de DML via SQL pela aplicação (HQL pode ser)
- Se existirem vários servidores a alterar a BD teriam todos que aceder a um middle layer de Model onde esta lógica estaria centralizada\
Posto estas limitações um uso muito interessante desta funcionalidade é para a gestão de cache de dados. Para evitar o acesso à BD podemos guardar os registos em RAM, mas precisamos saber quando os mesmos foram alterados para invalidar o cache.
Foi precisamente esse o caso de uso que me levou a criar a funcionalidade.
Segue o código deste exemplo: Numa Application class método @init
// Declare triggers
DIFModelTriggers.registerTrigger(SurveyRevisor.class, DMLOperation.ALL, new IDIFModelTrigger<SurveyRevisor>()
{
/**
* Execute.
*
* @param bean the bean attributes
* @param operation the operation
*/
@Override
public void execute(SurveyRevisor surveyRevisor, DMLOperation operation)
{
ComQuestFlow.invalidateSurveyRevisorsCache(surveyRevisor.getSurveyId());
}
});
Claro que este exemplo não apanharia alterações de dados na BD e assim esse cache poderia ficar desatualizado. Em situações em que isso seja um problema será boa prática ter um adicional invalidador de cache a cada X segundos (usar a feature de gestão de cache da DIF).
Disponível no Development, DIF 2.7.4
Com os melhores cumprimentos,