POG ColdFusion para identificar registros que nao podem ser excluidos de uma tabela
Odeio POGs. Em primeiro lugar porque a exigência comigo mesmo faz com que eu não descanse até encontrar uma solução verdadeiramente elegante.
A situação desta vez foi a seguinte: Se vocês repararem, todos os sistemas que a gente encontra por ai, no CRUD apresentam a possibilidade de excluir qualquer registro, verificando no momento da transação (server-side) se aquela ação é realmente possível ou não. Se possível, simplesmente efetiva, senão retorna uma mensagem para o usuário. A minha intenção é já desabilitar a opção de excluir na interface, prevendo tal condição. Para isso, preciso que no momento de mandar os registros de uma tabela para serem apresentados na interface, eu verifique se estes não são referenciados de alguma forma.
Conversando com meu amigo Jefferson Petilo, primeiro definimos o que era óbvio. Precisaríamos no banco de dados que fosse, utilizar as restrições de operação entre registros das tabelas através de chaves estrangeiras. Considere:
Tabela1 (TiposDeImagens):
| Campo | Tipo | Função |
| id | (uuid, int, etc) | Chave Primaria |
| label | (varchar) | Descrição do tipo |
Tabela2 (Imagens):
| Campo | Tipo | Função |
| id | (uuid, int, etc) | Chave Primaria |
| label | (var char) | Descrição da imagem |
| tipo | (uuid, int, etc) | Chave Estrangeira OnDelete = restrito |
Logo depois, por não encontrar nada universal no SQL ou que pudessemos facilmente replicar para vários banco de dados, decidimos que a melhor maneira de verificar registro por registro (no exemplo, da Tabela1, TiposDeImagens) quanto a possibilidade do mesmo ser excluído, seria:
Porém isso, claro, na ocasião de ser disparado contra um registro que não possui ligações, ocasionaria na exclusão do registro em sí.
Ai entra o POG:
O <cftransaction> com o ROLLBACK logo após o teste de deleção do registro, garante que o mesmo não seja efetivamente excluído.
Continuando a conversa com o Jefferson verificamos ainda a implementação desta solução via “trigger/actions” no banco de dados. Qual não foi a nossa surpresa ao reparar que o “POG” acabou sendo uma solução bem mais simples de se implementar.
Outra coisa em relação ao uso de “triggers/actions” é o fato de tornar a solução dependente de banco de dados e implicar em se ter várias versões de um código relativo a um mesmo e único recurso. Mas essa é definitivamente outra discussão de prós e contras.
O que fica para mim agora, é o desejo de estudar alguma solução, que seja ao mesmo tempo “elegante” (antônimo de POG, embora eu e o Jefferson tenhamos considerado este POG como “elegante”) e simples de ser implementada.
