Pour les données persistantes en Terracotta, comment faire évoluer les classes ?

Question

Nous envisageons Terre cuite pour notre prochain projet.Je suis intrigué par son potentiel à assurer la persistance des données sans avoir besoin d'un SGBD séparé.(Voir également Sur l'utilisation de Terracotta comme solution de persistance)

L'une des principales difficultés de l'évolution des logiciels est de rendre les données de production existantes conformes au nouveau modèle de données.Pour un SGBDR, vous utiliserez probablement un script de modification SQL au moment du déploiement.Pour les données basées sur Terracotta, je ne vois pas immédiatement comment gérer une évolution non triviale.

Il y a un quelques paragraphes sur l'évolution des classes dans la documentation Terracotta mais cela semble spécifique au DSO et reste plutôt superficiel.

1. Quels sont les moyens possibles de gérer l'évolution du modèle de données pour les données persistantes stockées dans Terracotta ? Je suis particulièrement intéressé par le scénario non-DSO (c'est-à-direvia l'API Terracotta Toolkit).
2. Terracotta DSO et l'API Toolkit diffèrent-ils dans leurs réactions aux définitions de classes évoluées ?
3. Pour comprendre les limites de l'évolution des classes, il serait utile de savoir comment Terracotta représente/communique les données des objets ;y a-t-il une spécification pour cela ?
4. Peut-être existe-t-il des techniques d'évolution de schéma du monde des SGBDO qui sont applicables à Terracotta ?

À titre d'exemple trivial, disons que j'ai un tas de Car objets stockés et j'ai changé le modelYear domaine de la Car classe d'un String à un int.Selon la documentation, cela ne fonctionne pas immédiatement.Je peux imaginer une solution où mon ancien Car est chargé par un chargeur de classe séparé lors du démarrage de l'application, puis converti en un nouveau Car.Serait-ce une bonne approche et pourquoi (pas) ?

Answer 1

Cela dépend de votre scénario de cas d'utilisation.

Si le coût de chargement de votre cache est minime (minutes) et que vous pouvez vous permettre de payer le temps ... alors je ne vois aucune question de simplement reconstruire votre cache pour une nouvelle version.

Si vous avez un coût élevé de remplissage de votre cache (heures / jours) et que vous ne pouvez pas vous permettre de réduire considérablement les temps d'arrêt, vous devez gérer une nouvelle et une nouvelle version en même temps pendant la période de transition. Pour cela:

1. Je définirais une définition de cache distincte pour toute nouvelle version de la classe mise en cache et laissez la vieille version à expirer dans le cache.
2. Le code d'application doit également avoir une "vieille / nouvelle version".
3. avoir une instance qui fonctionnerait toujours avec une ancienne version jusqu'à ce que des données expire / obsolète (basé sur un ancien nom de cache)
4. avoir une instance qui gère toutes les nouvelles demandes / flux avec une nouvelle version (basée sur un nouveau nom de cache)

   E.g. dans ehcache.xml vous définiriez 2 caches (en fonction de votre exemple):

   <cache name="com.xyz.Car" timeToLiveSeconds="600"/>
   <!--New version goes here-->
   <cache name="com.xyz.Car2" timeToLiveSeconds="600"/>
   

   À long terme, vous devriez faire l'entraînement de la convention de nommage pour vos caches qui inclut la version Evolution.