要学习lagom,我创建了一个简单的应用程序,其中包含一些简单的持久性实体和持久性读取面(根据官方文档,使用cassandra)
官方文档包含section about model evolution,描述了如何更改模型。但是,在读取方面并没有提及进化。
假设我有一个名为Item
的实体,其中有一个ID
和一个name
,并且读取端创建了一个像CREATE TABLE IF NOT EXISTS items (id TEXT, name TEXT, PRIMARY KEY (id))
的表
我现在想更改项目以包含描述。对于持久性实体来说,这是微不足道的,但是读取端也必须更改。
我可以看到几种实现(也许)实现这一目标的方法:
update table
中包含createTables
条语句来迁移模型哪种方法最合适?有更好的东西吗?
答案 0 :(得分:2)
创建新表并删除旧表也是恕我直言。 只需修改“创建表”命令(“创建表mytable_v2 ...”和“放置表mytable ...”)并更改偏移量名称并修改事件处理程序即可。
override def buildHandler( ): ReadSideProcessor.ReadSideHandler[MyEvent] = {
readSide.builder[MyEvent]("myOffset") // change it to "myOffset_v2"
...
}
这将导致重播所有事件,并从头开始重建读取的边表。如果当前表确实很大,那么这可能不是一个选择,因为重建可能会持续很长时间。
关于@erip所说的内容,我认为在读取的副表中添加新列完全正常。假设此表中有很多记录,其中包含所有实体的列表,并且您希望基于某些条件来检索实体列表,因此您需要在where子句中包括一些列。检索所有实体的列表并询问它们是否符合条件根本不是一个选择-这可能非常无效率,因为它需要更多的时间,内存和网络使用率。
答案 1 :(得分:0)
读取侧的目的是从服务中服务事件流的实体状态更改中实现视图。在这方面,您作为服务控制者可以决定对于订户要了解的重要事项。这是通过创建带有反腐败层(或ACL)的读取端来解决的。
通常,您的订阅者将订阅API事件,该事件不会经历任何演变。您的内部事件(或暗示事件) 可能需要发展;因此,应该从impl到API进行转换。
这就是为什么在设计之前非常仔细地考虑您的域非常重要的原因:您确实需要确定订户需要了解的内容。在描述的情况下,订阅者不太可能需要(或想要!)了解这一点。