对于Terracotta中的持久数据，如何演化类？

Question

我们正在考虑 红陶 对于我们的下一个项目。我对它无需单独的 DBMS 即可提供数据持久性的潜力很感兴趣。（也可以看看 关于使用 Terracotta 作为持久性解决方案)

软件演进的一大痛点是让现有的生产数据符合新的数据模型。对于 RDBMS，您可能会在部署时使用 SQL 更改脚本。对于 Terracotta 支持的数据，我并不清楚如何处理非平凡的进化。

有一个 Terracotta 文档中有几段关于类进化的内容 但它似乎是 DSO 特有的并且仍然相当肤浅。

1. 有哪些可能的方法来处理 Terracotta 中存储的持久数据的数据模型演变？ 我对非 DSO 场景特别感兴趣（即通过 Terracotta Toolkit API）。
2. Terracotta DSO 和 Toolkit API 对演化类定义的反应是否不同？
3. 要理解类演化的局限性，了解 Terracotta 如何表示/传达对象数据将有所帮助；有规范吗？
4. 也许 OODBMS 世界中有适用于 Terracotta 的模式演化技术？

作为一个简单的例子，假设我有一堆 Car 存储的对象，我已经改变了 modelYear 的领域 Car 类来自 String 到一个 int. 。根据文档，这不能开箱即用。我可以想象一个解决方案，我的旧 Car 在应用程序启动期间由单独的类加载器加载，然后转换为新的 Car. 。这是一个好方法吗？为什么（不是）？

Answer 1

这取决于您的用例场景。

如果加载缓存的成本很小（几分钟）并且您可以承受停机时间...那么我认为简单地为新版本重建缓存没有问题。

如果您填充缓存的成本很高（数小时/天），并且无法承受任何相当大的停机时间，那么您必须在过渡期间同时处理新旧版本。为了这：

1. 我将为任何新版本的缓存类定义一个单独的缓存定义，并让旧版本在缓存中过期。
2. 应用程序代码也应该具有“旧/新版本”支持。
3. 拥有一个仍然可以使用旧版本的实例，直到数据到期/过时（基于旧的高速缓存名称）
4. 拥有一个用新版本处理所有新请求/流的实例（基于新的缓存名称）

例如在 ehcache.xml 中，您将定义 2 个缓存（基于您的示例）：

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

从长远来看，您应该制定缓存的命名约定，包括版本演变。