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. 以某种方式在update table中包含createTables条语句来迁移模型
3. 创建包含其他信息的其他表，并保留旧表而无需修改

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

Answer 1

创建新表并删除旧表也是恕我直言。 只需修改“创建表”命令（“创建表mytable_v2 ...”和“放置表mytable ...”）并更改偏移量名称并修改事件处理程序即可。

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

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

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

Answer 2

读取侧的目的是从服务中服务事件流的实体状态更改中实现视图。在这方面，您作为服务控制者可以决定对于订户要了解的重要事项。这是通过创建带有反腐败层（或ACL）的读取端来解决的。

通常，您的订阅者将订阅API事件，该事件不会经历任何演变。您的内部事件（或暗示事件） 可能需要发展；因此，应该从impl到API进行转换。

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