我想在游戏中使用Evolutions,但是我发现Hibernate在开发中发生了很大的冲突,这使它变得痛苦而不是一个现实的选择.在开发过程中,Hibernate可以轻松管理所有内容,因此使用Evolutions没有任何意义,但是我们希望保留结构(文件),以便在生产模式下更轻松地迁移应用程序.但由于冲突,似乎不值得.
Liquibase有一个Play模块,但似乎已经停止了Evolutions发布(我不知道为什么,因为我相信它会有奇迹与Hibernate).
问题是：
>如何管理应用程序在生产中的数据库迁移？
>当您的模型在版本之间发生变化并且您必须部署到生产中时,通常使用的步骤/步骤如何？
>任何具体的Hibernate工具或功能我们都可以俯瞰,还是只是老旧的sql Alter表和类似的？
>专注于Play Framework,你如何管理这个？
解决方法
> Liquibase是一个成熟的解决方案,即使插件还没有开发,底层库就是这样.所以我觉得这是一个可以接受的解决方案
>如果您使用Evolution,与liquidibase相比有一个很大的缺点：您必须直接编写sql,因此脚本取决于您的数据库系统.考虑布尔和在不同数据库中的表示.所以你失去了Hibernate给你的好处.
现在一般的问题.我想你必须选择：
让Hibernate为你处理数据库结构.只有在Hibernate无法完成这项工作的情况下,您才能使用液体或者进化.不幸的是,如果您有复杂的更新场景,可能会遇到麻烦.你如何赢得你的发展更快.
>忽略来自Hibernate的所有DDL功能,并使用液体或者进化来做所有的事情.这是最可靠和最强大的解决方案,但显然你有更多的开发工作.
那么我的建议是什么？我将尝试以下方法：使用分布式版本控制系统(如bzr或git)进行开发.然后使用特征分支.用于功能分支始终是休眠功能.在将这些内容合并到中继线之前,请创建一个液相脚本.这些脚本可以通过一些手动定制的液体生成).所以你可以非常快速地开发一个功能,并且在中继线总是强大的解决方案2.
如何知道这在伟大的项目中不是一个证明的方法.我只是在一个小项目中用Hibernate和Liquibase测试了这个策略 – 它工作正常.
那么得到反馈就很好
