Lagom 持久读端和模型演化

Question

为了学习 lagom，我创建了一个简单的应用程序，其中包含一些简单的持久实体和持久读取端（根据官方文档，使用 cassandra）

官方文档包含一个section about model evolution，描述了如何更改模型。但是，在读取方面没有提及进化。

假设我有一个名为Item 的实体，有一个ID 和一个name，并且读取端会创建一个类似CREATE TABLE IF NOT EXISTS items (id TEXT, name TEXT, PRIMARY KEY (id)) 的表

我现在想更改项目以包含描述。这对于持久实体来说是微不足道的，但读取端也必须更改。

我可以看到几种方法来（也许）实现这一目标：

1. 使用 liquibase 或play evolutions 等模型演化工具来更改读取边表。
2. 以某种方式在createTables 中包含update table 语句以迁移模型
3. 创建包含附加信息的附加表，并保留旧表而不进行修改

哪种方法最合适？有更好的吗？

Answer 1

恕我直言，创建新表并删除旧表也是一种选择。 修改“create table”命令（“create table mytable_v2 ...”和“drop table mytable...”）并更改偏移名称和修改事件处理程序很简单。

override def buildHandler( ): ReadSideProcessor.ReadSideHandler[MyEvent] = {
      readSide.builder[MyEvent]("myOffset") // change it to "myOffset_v2"
      ...
}

这会导致重播所有事件，并从头开始重建您的读取边表。如果当前表真的很大，这可能不是一个选项，因为重建可能会持续很长时间。

关于@erip 所说的，我认为在您的阅读边表中添加一个新列是完全正常的。假设此表中有很多记录，其中包含所有实体的列表，并且您希望根据某些条件检索实体列表，因此您需要在 where 子句中包含一些列。检索所有实体的列表并询问每个实体是否符合标准根本不是一种选择 - 因为它需要更多的时间、内存和网络使用，所以效率可能非常低。

Answer 2

读取端的重点是从服务中的服务事件流中的实体状态更改中具体化视图。在这方面，您作为服务控制者可以决定您的订阅者需要了解的重要信息。这是通过创建带有防损坏层（或 ACL）的读取端来处理的。

通常情况下，您的订阅者会订阅 API 事件，这些事件不会发生任何变化。您的内部事件（或 impl 事件）将可能需要发展；因此，应该有从 impl 到 API 的转换。

这就是为什么在设计之前仔细考虑您的域非常重要：您确实需要确定订阅者需要了解的内容。在描述的情况下，我觉得订阅者不太可能需要（或想要！）知道这一点。