4D veille à ce que vos sélections de données soient cohérentes en ce qui concerne la suppression des données.

La suppression des données doit être effectuée avec précaution. Pour éviter les problèmes, nous pouvons utiliser des transactions ou nous appuyer sur des sauvegardes et des journaux.

Certaines améliorations ont été apportées à 4D 20 R4 pour rendre vos sélections d’enregistrements stables et cohérentes en ce qui concerne la suppression potentielle d’enregistrements dans cette sélection.

Poursuivez votre lecture pour découvrir comment votre code 4D sera plus sûr.

Comportement interne de 4D

Comme vous le savez peut-être déjà, 4D gère en interne une table d’adresses pour pointer sur des blocs physiques de données sur le disque. La gestion de cette table d’adresses dans l’architecture interne de 4D peut entraîner les problèmes évoqués ici lors de la sélection d’enregistrements.

Lorsqu’un enregistrement est supprimé, sa référence aux données physiques est supprimée dans la table d’adresses.

Pour éviter les trous et optimiser l’utilisation de la mémoire pour la table d’adresses, lorsqu’un nouvel enregistrement est créé, 4D réutilise les espaces libres dans cette table d’adresses.

Une fois que vous avez construit une sélection d’enregistrements (par exemple avec une requête), si un enregistrement appartenant à cette sélection est supprimé et qu’un nouvel enregistrement est créé, il peut être référencé par le même numéro d’enregistrement précédent dans la table d’adresses.

Ainsi, dans le passé, vous avez pu trouver dans votre sélection des données auxquelles vous ne vous attendiez pas du tout.

Un exemple concret

Un employé doit s’occuper d’une pile de tâches. Lorsqu’elle est créée, la tâche lui est affectée avec le statut À FAIRE.

Périodiquement, un courrier est envoyé à l’employé avec ses tâches à faire. Une sélection de ces tâches est établie et il y a une boucle sur chacune d’entre elles pour fournir les détails dans l’e-mail.

Mais l’administrateur a le droit de supprimer certaines tâches. Si l’administrateur supprime par erreur une tâche dans la sélection ci-dessus et qu’une nouvelle tâche est créée juste après pour un autre employé… que se passe-t-il ?

Avant 4D 20 R4

La tâche nouvellement créée a été trouvée dans la boucle et comme il s’agit d’une tâche pour un autre employé, elle est complètement hors du champ d’application !

Après 4D 20 R4

La tâche nouvellement créée n’est pas trouvée dans la boucle et la sélection des données est toujours cohérente et vous pouvez vous y fier en toute sécurité.

Le cas d’utilisation ci-dessus n’est pas si fréquent, car la plupart du temps, nous modifions le statut d’un enregistrement au lieu de le supprimer directement.

Ou peut-être avez-vous l’habitude de vérifier à nouveau la cohérence d’un enregistrement / d’une entité (par rapport aux critères de sélection) avant de le / la traiter.

Quoi qu’il en soit, vous n’avez plus à vous en préoccuper.

Voyons cela en action dans un peu de code

Dans l’exemple ci-dessous, nous construisons la sélection d’entités $target.

Ensuite, nous supprimons une entité appartenant à cette sélection d’entités (nous le faisons dans le même morceau de code pour une compréhension rapide, mais nous pouvons imaginer que cela est fait par un autre utilisateur dans un autre process).

La boucle ne traite que les deux entités restantes (internalID 10 et 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 

Important: cette fonctionnalité s’applique aux données traitées avec les commandes QUERY classiques de 4D et ORDA.

Continuez à travailler avec 4D en toute sécurité, car votre plateforme de développement préférée prend en charge de nombreuses préoccupations pour vous permettre de vous concentrer sur votre logique métier !