Comment gérer la modification de l’implémentation des événements lors de l’utilisation de Data.Acid

J’ai une application de taille modérée qui utilise Data.Acid pour la persistance et j’ai rencontré une situation où je dois mettre à jour l’implémentation de l’un de mes événements de Update pour la prochaine version du serveur. Ie j’ai quelque chose comme

 myUpdate :: Update MyState () myUpdate =  

Maintenant, de toute évidence, je ne peux pas simplement changer l’implémentation au hasard car cela corromprait mon historique de transactions, alors je me demandais comment les gens géraient habituellement cela. La façon dont je le vois mes options sont les suivantes:

  1. Arrêtez le serveur. Exécutez createCheckpoint pour mon AcidState . Mettez à jour la mise en œuvre de l’ Event , puis redémarrez le serveur. Étant donné que nous chargeons à partir d’un nouvel instantané, la Update modifiée ne doit jamais déclencher pour les anciens événements.

  2. Créez une nouvelle Update à Update avec un nouveau nom (comme myUpdate_v2 ) et mettez à jour la logique de mon serveur pour n’utiliser myUpdate_v2 qu’au lieu de myUpdate original.

Je pense que les deux options ont leurs mérites. (1) est plus agréable car je n’ai pas besoin de conserver les anciennes fonctionnalités dans mon code mais cela doit être fait avec beaucoup de soin pour chaque serveur que je mets à jour ou je risque de corrompre les données. (2) est plus sûr (surtout si je supprime l’ancien myUpdate des myUpdate de mon module pour être sûr de ne pas utiliser accidentellement l’ancienne implémentation), mais la situation est un peu moche.

Y a-t-il une meilleure façon de le faire? Je vois cela comme quelque chose que je vais certainement rencontrer de temps en temps dans un projet de longue haleine, alors je voudrais avoir un bon workflow standard pour appliquer les changements à l’implémentation de mes événements.

La solution consiste à ne pas utiliser les fonctions d’ordre supérieur telles que «alter». Les avantages de l’acide-état (garanties ACID, exécution de code à distance, etc.) se font au prix de l’utilisation exclusive de données sérialisables. Il est peu probable que cette ressortingction soit levée.

Habituellement, ce n’est pas un gros problème. Il suffit de spécialiser votre code. Si cela ne suffit pas, vous voudrez peut-être garder votre état dans un MVar.