États des entités

L’un des besoins du modèle est de permettre la restauration des entités détruites « par erreur ». Il est important de prendre en compte ce problème dès les premiers stades de la réflexion car il a d’importants impacts sur la gestion du cycle de vie des entités.

A.1.1 Restauration

Une première approche consiste en l’utilisation d’un journal pour pister les modifications faites du- rant la suppression, de façon à les restaurer si besoin. Toutefois, cette approche ne permet de restaurer que la dernière entité et correspond davantage à une option d’annulation.

Une seconde approche est de simplement marquer les objets comme « condamnés » en les plaçant dans une « poubelle » de façon à pouvoir les restaurer dans leur état complet à tout moment.

Nous avons privilégié la seconde approche, cette dernière étant plus simple et offrant plus de fonc- tionnalités. Toutefois, elle a des impacts importants, qui peuvent être vus autant comme des avantages que des inconvénients en fonction des besoins :

• Il est possible de condamner une entité même s’il existe des références dessus ; seule la destruction finale est alors bloquée. La présence d’une entité dans la poubelle n’est donc qu’indicative. • Comme aucune référence n’est vérifiée, il est possible de condamner toute instance. Cette fonc-

tionnalité est particulièrement utile quand quelqu’un veut détruire un ensemble d’entités contenant de nombreuses références entre elles (éventuellement des cycles). Avec une suppression directe, un tel ensemble serait indestructible sans une gestion spécifique, complexe et coûteuse. En utilisant une poubelle, cette tâche peut être efficacement déléguée à un processus asynchrone.

• Lorsqu’elle est dans la poubelle, une entité n’est pas accessible directement, tout du moins en utilisant les vues standards car comme expliqué ci-dessous, les vues d’administration permettent d’accéder aux instances condamnées. Une application peut cependant montrer cet état dans les entités la référençant avec, par exemple, une icône spécifique.

A.1.2 Deux ensembles d’entités

Durant sa durée de vie, une entité peut donc être dans deux états : • Vivante

• Condamnée

Quel que soit son état, une entité est toujours cohérente et fonctionnelle, c’est-à-dire que même si elle est condamnée, ses références sortantes et entrantes ne sont pas modifiées. Les mises à jour ne sont appliquées que lors de la destruction effective. L’état « condamnée » n’est donc qu’indicatif.

En correspondance avec ces états, nous distinguons deux ensembles d’entités : • Entity, l’ensemble de toutes les entités vivantes ;

• EntityBin, l’ensemble de toutes les entités condamnées.

Ces deux ensembles correspondent à des vues du noyau dans le SGBDR sous-jacent. Les deux in- cluent tous les champs additionnels normaux (ex. : date de création, ACL1, etc.).

Nous définissonsEntityAll comme l’ensemble de tous les objets du système, tel que : EntityAll = Entity ∪ EntityBin

Entity ∩ EntityBin = ∅

Cet ensemble est aussi disponible en tant que vue dans le SGBDR avec la même information que les autres, plus un champ additionnel « state » qui correspond à l’état courant de l’entité : vivante ou condamnée.

D’autre part, nous définissonsEntityDestructionCandidate comme un sous-ensemble de EntityBin qui contient tous les objets deEntityBin qui sont disponibles pour suppression. La destruction effective étant asynchrone, la durée pendant laquelle une entité peut rester dans cet état n’est pas connue.

EntityDestructionCandidate ⊂ EntityBin

Les règles indiquant si une instance présente dans la poubelle est aussi candidate à la destruction dépendent de l’application. La destruction peut entre autres être déclenchée par un utilisateur, dépendre d’un paramètre de « longévité » minimale, ou encore dépendre du nombre total d’entités dans la poubelle (analogue à la définition de la taille de la poubelle de Windows).EntityDestructionCandidate étant une simple vue sur le SGBDR sous-jacent, il est aisé de l’adapter à tout besoin.

A.1.3 Interactions entre les états

La figure A.1 nous montre les deux états possibles d’une entité et leurs interactions. 2

Entity EntityBin

1 4

3

Figure A.1 – Intéractions entre les états d’une entité

Comme nous pouvons l’observer, il existe quatre opérations influant sur l’état d’une entité :

1

ANNEXE A 165

1. Entity_Create : Création d’une entité. Elle est directement vivante et disponible dans l’en- sembleEntity.

2. Entity_Condemn: Condamnation d’une entité. Elle n’est pas détruite mais simplement placée dans la poubelle. La présence de références ne bloque pas cette action.

3. Entity_Restore: Restauration d’une entité. Elle est de nouveau disponible dans un état cohé- rent.

4. Entity_Destroy: Destruction d’une entité. Cette opération est généralement appelée par un pro- cessus asynchrone et non par un utilisateur. Pour être détruite, une entité doit être candidate, c’est- à-dire appartenir au sous-ensemble EntityDestructionCandidate, et il ne doit pas y avoir de référence dessus. Sinon, elle reste dansEntityBin.

Quelques notes sur la destruction. Plusieurs cas peuvent empêcher la destruction d’une entité : • L’entité est référencée par une autre instance qui n’est pas candidate à la destruction : elle est

indestructible et le restera tant qu’elle est référencée de cette façon.

• L’entité est référencée par une instance elle-aussi candidate à la destruction : elle est indestructible pour l’instant, mais dès que cette autre entité sera détruite (c’est-à-dire que la référence sera sup- primée), elle deviendra destructible. La destruction réelle aura donc lieu dans une future passe du processus.

• L’entité fait partie d’un ensemble d’objets ayant des références entre eux (cycle). Comme la gestion de ce cas particulier est potentiellement coûteuse, elle n’est déclenchée que lorsqu’un tel état a une forte probabilité d’exister (par exemple si le nombre d’entités indestructibles est stable entre deux passes du processus de destruction).