Para datos persistentes en Terracotta, ¿cómo evolucionan las clases?

Question

Estamos considerando Terracota para nuestro próximo proyecto.Me intriga su potencial para proporcionar persistencia de datos sin la necesidad de un DBMS separado.(Ver también Sobre el uso de Terracotta como solución de persistencia)

Uno de los mayores problemas de la evolución del software es hacer que los datos de producción existentes se ajusten al nuevo modelo de datos.Para un RDBMS, probablemente usaría un script de cambio de SQL en el momento de la implementación.Para los datos respaldados por Terracotta, no me queda claro de inmediato cómo lidiar con la evolución no trivial.

Hay una un par de párrafos sobre la evolución de clases en la documentación de Terracotta pero parece específico de DSO y sigue siendo bastante superficial.

1. ¿Cuáles son las posibles formas de manejar la evolución del modelo de datos para los datos persistentes almacenados en Terracotta? Estoy particularmente interesado en el escenario sin DSO (es decir,a través de la API Terracotta Toolkit).
2. ¿Terracotta DSO y Toolkit API difieren en sus reacciones a las definiciones de clases evolucionadas?
3. Para comprender las limitaciones de la evolución de clases, sería útil saber cómo Terracotta representa/comunica datos de objetos;¿Existe una especificación para eso?
4. ¿Quizás existan técnicas de evolución de esquemas del mundo OODBMS que sean aplicables a Terracotta?

Como ejemplo trivial, digamos que tengo un montón de Car objetos almacenados y he cambiado el modelYear campo de la Car clase de un String a una int.Según la documentación, esto no funciona de inmediato.Puedo imaginar una solución donde mi viejo Car se carga mediante un cargador de clases separado durante el inicio de la aplicación y luego se convierte a un nuevo Car.¿Sería ese un buen enfoque y por qué (no)?

Answer 1

Depende del escenario de su caso de uso.

Si el costo de cargar su caché es mínimo (minutos) y puede permitirse el tiempo de inactividad... entonces no veo ningún problema en simplemente reconstruir su caché para una nueva versión.

Si tiene un alto costo para llenar su caché (horas/días) y no puede permitirse un tiempo de inactividad considerable, entonces debe manejar la versión nueva y la antigua al mismo tiempo durante el período de transición.Para esto:

1. Definiría una definición de caché separada para cualquier versión nueva de la clase almacenada en caché y dejaría que la versión anterior expire en el caché.
2. El código de la aplicación también debe ser compatible con "versión antigua/nueva".
3. Tenga una instancia que aún funcione con la versión anterior hasta que los datos expire/obsoletos (según un nombre de caché antiguo)
4. Tener una instancia que manejara todas las nuevas solicitudes/flujos con una nueva versión (basada en un nuevo nombre de caché)

p.ej.en ehcache.xml definirías 2 cachés (según tu ejemplo):

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

A largo plazo, deberías ejercitar una convención de nomenclatura para tus cachés que incluya la evolución de las versiones.