【发布时间】:2017-03-07 20:49:38
【问题描述】:
将表生成保留在生产代码中是一种好习惯吗?
我也是指:
Await.ready(database.autocreate().future(), 2 minutes)
留下这个有什么潜在的问题吗?只是寻找一些关于这是否是个好主意的解释。
在初始部署和迁移期间将此类工作保留在某种脚本中运行是否更好?
【问题讨论】:
标签: scala phantom-dsl
将表生成保留在生产代码中是一种好习惯吗?
我也是指:
Await.ready(database.autocreate().future(), 2 minutes)
留下这个有什么潜在的问题吗?只是寻找一些关于这是否是个好主意的解释。
在初始部署和迁移期间将此类工作保留在某种脚本中运行是否更好?
【问题讨论】:
标签: scala phantom-dsl
我完全不同意上面给出的所有建议。 phantom 的全部意义在于永远不必编写 CQL,我们拥有完整的机制,可让您控制架构的初始化方式,包括所有可能的属性。
看看测试 here 或默认的 Cassandra 初始化,几乎没有什么是你做不到的。
自动创建中的自定义设置
如果您想在database.autocreate 期间提供所有这些参数而不是默认值,那也很简单:
class MyTable extends CassandraTable[MyTable, MyRecord] {
override def autocreate(
keySpace: KeySpace
): CreateQuery.Default[T, R] = create.ifNotExists()(keySpace)
.`with`(compaction eqs LeveledCompactionStrategy.sstable_size_in_mb(50))
.and(compression eqs LZ4Compressor.crc_check_chance(0.5))
}
稍后当你这样做时:
class MyDB(override val connector: KeySpaceDef) extends Database {
object myTable extends MyTable with connector.Connector
}
你做到了:
val database = new MyDB(ContactPoint.local.keySpace("whatever")
当您运行database.createAsync 或database.create 时,您在上面定义的所有设置都将得到遵守。
自定义键空间自动创建
Phantom 还支持在键空间自动生成期间指定自定义键空间初始化查询。
val init = KeySpaceSerializer("my_app").ifNotExists()
.`with`(replication eqs SimpleStrategy.replication_factor(2))
.and(durable_writes eqs true)
val connector = ContactPoint.local.keySpace(
"my_app",
(session, space): (Session, KeySpace) => init.queryString
)
通过这种方式,您可以从您能想到的任何已知形式的定制中受益,同时还不必处理 CQL。如果您使用很快可以订阅的phantom-pro,那么还会有自动模式迁移功能,因此将您的模式保存在任何类型的 CQL 中都是一个非常大的禁忌。
Phantom 还透明地处理版本之间的 CQL 变化,我从未见过这样做的 bash 脚本,因此您可以通过简单的 Cassandra 升级/降级很快陷入不愉快,如果您可以自动执行这些操作,您为什么要这样做?
【讨论】:
ifNotExists,所以整个事情是幂等的,它不会覆盖任何设置。对 Cassandra 的几次调用不会真正对您的整体性能产生任何影响,您甚至不会觉得它们真的存在。由于我们放弃了反射,即将推出的 Phantom 2.0.0 甚至更快。
表创建/修改逻辑可能在安装或升级后一次就没有用了。此外,将其保存在生产代码中可能不安全/不需要。因此,请将您的代码/脚本保持在引导程序或安装程序级别。
【讨论】:
正如已经指出的那样,根据我的经验,这不是您想要的。 我已经在生产环境中使用 phantom 一年多了,唯一让表创建成为自动的地方是在我的测试中,使用嵌入式版本运行。
为了进一步推动它,与 hibernate 有类似的讨论。你可以看这里:Hibernate/JPA DB Schema Generation Best Practices
【讨论】: