最接近的等同于 SQLAlchemy for Java/Scala [已关闭]

SQLAlchemy 的一个值得注意的事情是它使表成为第一类对象。因此，核心 API 实际上是围绕表对象编写的，因此 API 本质上是关系性的。因此，在这个级别，即使API是OO，它本质上也反映了RDBMS对象或函数，如表，列，关系，连接，别名等。在这个级别上，SQLAlchemy基本上为您提供了一个OOSQL，其中SQL和关系数据库没有给出第二类处理。SQLAlchemy也在这方面大放异彩，因为这种抽象级别使您能够降级到一个“原始”关系级别，从而获得巨大的灵活性，我真的没有看到任何其他ORM产品。有趣的是，在ORM中对类继承进行建模所需的一些底层功能是在这一层实现的，例如。联接表继承 http://docs.sqlalchemy.org/en/rel_0_7/orm/inheritance.html#joined-table-inheritance

更常用的API（至少最近）是声明式API，它实际上有更多的OO，并将业务域中的对象映射到我上面提到的对象（在大多数情况下是透明的）。这是ORM功能的用武之地，API与其他ORM API更相似，在ORM API中，人们使用域对象，这些操作直接转换为基础表操作。

据我所知，Scala中的ORM仍然在追赶Java中容易获得的功能（例如继承），即使它们提供了其他功能（例如类型安全，类似LINQ的构造），即使它们正在努力解决一些严重的问题，例如22列限制。（我读过一些评论，很少有人想知道为什么有人需要超过22列，至少根据我的经验，有些情况我不会称之为罕见，其中需要一个倍数）。

scala中的ORM（即使它们与Java具有不同的风格）我认为仍然在满足需求。关于SQLAlchemy，有没有一个足够接近我在Java或Scala中看到的等价物？我没见过。

编辑：我忘了补充的一件事是，即使使用声明性API，SQLAlchemy仍然允许您直接访问底层对象。因此，如果以声明方式映射“类 Foo”，则Foo.__table__是可以根据需要直接使用的表对象。

Squeryl提供的可组合性类似于他们在库主页上的“SQLALCHEMY'S PHILOSOPHY”中谈论的内容。您可以查询查询。

val query = from(table)(t => where(t.a === 1) select(t))
val composed = from(query)(q => where(q.b === 2) select(q))

它还分享了设计理念的很大一部分，主要是当事情变得复杂时，库应该“摆脱困境”，并允许开发人员自己调整。虽然Squeryl做对象映射，但我认为它更像是DSL而不是ORM。

它无法通过快速浏览 SQLAlchemy 功能列表来共享的一些功能：

1. 使用原始SQL的能力 - 很难在标准ANSI SQL中找到任何无法表达的东西。
2. 继承映射 - 这里有一些个人意见，但我认为当一个图书馆这样做时，它经常违反“摆脱困境”的原则。

当然，Squeryl还提供了我认为Python库无法提供的主要功能，即编译器检查查询的类型安全性。