A eliminação de dados deve ser tratada com cuidado. Para prevenir problemas, podemos usar transações ou confiar em backups e logs.
Algumas melhorias foram feitas em 4D 20 R4 para fazer suas seleções de registros estáveis e consistentes em relação à potencial eliminação de registros nessa seleção.
Continue lendo para aprender como seu código 4D será tão seguro fora da caixa.
Comportamento interno de 4D
Como já deve saber, 4D lida internamente com uma tabela de endereços para apontar para blocos físicos de dados no disco. Em relação ao manuseio dessa tabela de endereços na arquitetura interna de 4D, isso pode levar aos problemas discutidos aqui quando se processa uma seleção de registros.
Quando um registo é apagado, sua referência aos dados físicos é apagada na tabela de endereços.
Para evitar buracos e otimizar o uso da memória para a tabela de endereços, quando um novo registro é criado, 4D reutiliza espaços livres nessa tabela de endereços.
Uma vez que tenha construído uma seleção de registros (por exemplo com uma consulta), depois disso, se um registro pertencente a essa seleção é apagado e um novo registro é criado, ele pode ser referenciado através do mesmo número de registro anterior na tabela de endereços.
Assim, no passado, poderia encontrar na sua seleção alguns dados que não esperava de todo.
um exemplo concreto
Um empregado tem uma pilha de tarefas para tratar. Quando criada, a tarefa é afetada pelo estado A FA ZER.
Periodicamente, é enviado um e-mail ao empregado com as suas tarefas TO DO. É criada uma seleção dessas tarefas e existe um ciclo em cada uma delas para fornecer os detalhes no e-mail.
Mas o administrador tem permissão para eliminar algumas tarefas. Se o administrador elimina por engano uma tarefa na seleção acima e uma nova tarefa é criada logo a seguir para outro empregado… o que acontece?
Antes de 4D 20 R4
A tarefa recém-criada foi encontrada no ciclo e, como é uma tarefa para outro funcionário, está completamente fora do âmbito!
Depois de 4D 20 R4
A tarefa recém-criada não é encontrada no ciclo e a seleção de dados é sempre consistente e pode confiar nela com segurança.
O caso de uso acima não é tão frequente porque na maioria das vezes alteramos um estado num registo em vez de o apagar diretamente.
Ou talvez esteja habituado a verificar novamente a coerência de um registo/entidade (em relação aos critérios de seleção) antes de o prosseguir.
De qualquer forma, já não precisa de se preocupar com isso.
Vamos ver isto em ação num código
No exemplo abaixo, construímos a seleção da entidade $target.
Depois disso, eliminamos uma entidade pertencente a esta seleção de entidades (fazemos isto no mesmo pedaço de código para uma rápida compreensão, mas podemos imaginar que isto é feito por outro utilizador noutro processo).
O loop processa apenas as duas entidades restantes (internalID 10 e 12).
var $target; $customers : cs.CustomersSelection
var $customer : cs.CustomersEntity
var $newCustomer : cs.CustomersEntity
var $status : Object
// Three customers are retrieved with internal ID 10, 11, 12
$target:=ds.Customers.query("internalID >= 10 and internalID <= 12")
ASSERT($target.length=3)
// We delete the customer with internalID = 11
$customers:=ds.Customers.query("internalID = :1"; 11).drop()
// We create a new customer with internalID = 99
$newCustomer:=ds.Customers.new()
$newCustomer.internalID:=99
$status:=$newCustomer.save()
// We loop on the $target entity selection
// got before the creation of the new customer
For each ($customer; $target)
// The new customer is not in the entity selection ...
ASSERT($customer.internalID#99)
End for each Importante: Esta caraterística aplica-se a dados manipulados com comandos QUERY padrão 4D clássicos e ORDA.
Continue trabalhando com 4D com segurança, já que sua plataforma de desenvolvimento favorita se encarrega de muitas preocupações para permitir que se concentre em sua lógica de negócios!