@lmshl 为了 Java 和 Kotlin 创建的 ORM ，搬 scala/typescript 出来怼几个意思啊？折不胡搅蛮缠吗？

完全无法看清一个革命性框架框架的和设计，只能在特性更多的编程语言中寻找嗨点，你的层次真的是堪忧啊。再者，scala 是你发明的还是你创造啊？

我唯一的错误，是在颠覆行业的方式不是以硅谷巨头的身份，而是以个人身份。为此，辞去工作并用爱点发现，还被各种小白陪，一直默默忍受，真的无语了。

我完全不在乎普通程序员会如何看待，我只在乎如何征服行业顶尖专家：俄联储首席技术专家讲 Jimmer, https://www.bilibili.com/video/BV1Cp13YdEQ3

在你认知层次实现跃迁之前，请对陌生的东西保持一份谨慎和客观，因为你无法判断对方是忽悠人的二逼，还是有真才实学完全不屑于炒作和骗人的那种。

@lmshl 俄联储首席技术专家讲 Jimmer, https://www.bilibili.com/video/BV1Cp13YdEQ3

@nothingistrue 这个动态树模型，针对忠于原始数据模型的 OLTP 功能，并非经过分析计算的 OLAP 功能（目前支持简单的计算属性，单还不支持 OLAP 数据库那种强烈分析能力，未来把复杂的计算属性映射到 OLAP 系统是未来的大规划之一）。这种返回业务分析指标的功能，和原始数据结构没什么关系，应该定义 DTO ，这种 DTO 不是 Jimmer 的反对对象。

Jimmer 彻底改变了开发人员看待关系型数据库的视角

针对特定业务场景，允许开发人员从全局的对象关系模型中，勾勒出当前业务场景关心的数据边界，即，选取一个局部的对象关系模型。然后，把这个局部数据结构作为一个整体，进行
a. 查询
b. 修改
c. 缓存

此视角的变化，可以让所有行业复杂业务的开发效率质变，事半功倍。

这个视角变化，是 Jimmer 的本质特征。

如果把用户随意截取的这个局部数据结构视作一个文档，那么 Jimmer 提供的就是文档数据库操作接口。然而，这比真正的文档数据库还好，因为，在文档数据库中，各文档的结构在设计数据库存储时就已经定死，完全固化且彼此孤立；而在 Jimmer 中，各文档边界是开发人员为每个业务场景“临时起意”而勾勒，变化无穷且可以彼此重叠。