2

将表生成保留在生产代码中是一种好习惯吗？

我也指：

Await.ready(database.autocreate().future(), 2 minutes)

把它留在里面有什么潜在的问题吗？只是寻找一些关于这是否是一个好主意的解释。

将此类工作保留在某种脚本中以在初始推出和迁移期间运行是否更好？

4

3 回答 3

1

我完全非常强烈地不同意上面给出的所有建议。phantom 的全部意义在于永远不必编写 CQL，并且我们拥有完整的机制，允许您控制架构的初始化方式，包括所有可能的属性。

看看这里的测试或默认的 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.createAsyncor时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 升级/降级很快陷入不愉快，如果您可以自动化操作，您为什么要这样做？

于 2016-10-25T22:35:05.020 回答
-1

正如已经指出的那样，根据我的经验，这不是您想要的。我已经在生产环境中使用 phantom 一年多了，唯一让表创建成为自动的地方是在我的测试中，使用嵌入式版本运行。

你可以在这里找到更多信息：https ://github.com/iamthiago/cassandra-phantom/blob/master/src/test/scala/com/cassandra/phantom/modeling/test/service/SongsTest.scala

为了进一步推动它，与hibernate有类似的讨论。你可以看看这里：Hibernate/JPA DB Schema Generation Best Practices

于 2016-10-25T21:07:39.533 回答
-1

表创建/修改逻辑可能在安装或升级后一次就没有用了。此外，将其保存在生产代码中可能不安全/不需要。因此，请将您的代码/脚本保持在引导程序或安装程序级别。

于 2016-10-25T18:20:07.920 回答