4D mantiene sus selecciones de registros consistentes en lo que respecta a la eliminación de registros

La eliminación de datos debe manejarse con precaución. Para evitar problemas, podemos utilizar transacciones o confiar en copias de seguridad y registros.

Se han hecho algunas mejoras en 4D 20 R4 para hacer que sus selecciones de registros sean estables y consistentes con respecto a la eliminación potencial de registros en esta selección.

Siga leyendo para saber cómo su código 4D será tan seguro desde el principio.

Comportamiento interno de 4D

Como ya sabrá, 4D maneja internamente una tabla de direcciones para apuntar a bloques físicos de datos en el disco. En cuanto al manejo de esta tabla de direcciones en la arquitectura interna de 4D, esto podría llevar a los problemas discutidos aquí cuando se procede a una selección de registros.

Cuando se suprime un registro, se suprime su referencia a los datos físicos en la tabla de direcciones.

Para evitar agujeros y optimizar el uso de memoria para la tabla de direcciones, cuando se crea un nuevo registro, 4D reutiliza los espacios libres en esta tabla de direcciones.

Una vez que se ha creado una selección de registros (por ejemplo, con una consulta), después de esto, si se borra un registro perteneciente a esta selección y se crea un nuevo registro, éste puede ser referenciado a través del mismo número de registro anterior en la tabla de direcciones.

En el pasado, podría encontrar en su selección algunos datos que no espera en absoluto.

un ejemplo concreto

Un empleado tiene que ocuparse de una pila de tareas. Cuando se crea, la tarea pasa al estado TO DO.

Periódicamente, se envía un correo al empleado con sus tareas TO DO. Se crea una selección de esas tareas y hay un bucle en cada una para ofrecer los detalles en el correo electrónico.

Pero el administrador tiene permiso para borrar algunas tareas. Si el administrador borra por error una tarea de la selección anterior y justo después se crea una nueva tarea para otro empleado… ¿Qué ocurre?

Antes de 4D 20 R4

La tarea recién creada se encuentra en el bucle y como es una tarea para otro empleado, ¡Está completamente fuera de alcance!

Después de 4D 20 R4

La tarea recién creada no se encuentra en el bucle y la selección de datos es siempre coherente y se puede confiar en ella con seguridad.

El caso de uso anterior no es tan frecuente porque la mayoría de las veces cambiamos un estado en un registro en lugar de borrarlo directamente.

O tal vez esté acostumbrado a comprobar de nuevo la coherencia de un registro / entidad (con respecto a los criterios de selección) antes de proceder.

En cualquier caso, ya no tiene que preocuparse por esto.

Veamos esto en acción en código

En el siguiente ejemplo creamos la selección de entidades $target.

Después de esto, borramos una entidad perteneciente a esta selección de entidades (hacemos esto en el mismo trozo de código para una rápida comprensión, pero podemos imaginar que esto lo hace otro usuario en otro proceso).

El bucle procesa sólo las dos entidades que quedan (internalID 10 y 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 funcionalidad se aplica sobre datos manejados con  comandos QUERY clásicos de 4D y ORDA.

Siga trabajando con 4D de forma segura ya que su plataforma de desarrollo favorita se hace cargo de muchas preocupaciones para permitirle concentrarse en su negocio.

 

 

Avatar
• Propietario de producto - Marie-Sophie Landrieu-Yvert ingresó al equipo de 4D Product como Propietario de producto en 2017. Como tal, está a cargo de escribir las historias de los usuarios y luego traducirlas en especificaciones funcionales. Su papel es también asegurarse de que la implementación de la funcionalidad entregada cumpla con las necesidades del cliente. Marie-Sophie se graduó en la Escuela de Ingeniería de ESIGELEC y comenzó su carrera como ingeniera en IBM en 1995. Participó en varios proyectos (de mantenimiento y creación) y trabajó como desarrolladora de Cobol. Luego trabajó como diseñadora de UML y desarrolladora de Java. Sus principales funciones fueron analizar y redactar requisitos funcionales, coordinar los equipos de negocio y de desarrollo.