Hibernate 方法论
我有一个由 Eclipse 项目表示的数据访问层。我使用 Hibernate 3 作为持久性框架。因此，在这个项目中，我有带注释的实体和 Hibernate 使用的资源（persistence.xml、XXX.cfg.xml）。
我现在的问题更多是关于质量保证和生产如何。我还有其他项目使用这个数据访问层。此外，我的实体可能会在项目发展过程中进行修改。 当我将其中一个项目发布给 QA 时，并且数据访问层已被修改（实体修改），QA 数据库也必须进行相应修改。生产也是如此。
此场景的最佳实践是什么？我使用 Maven 作为构建系统。您认为使用 hibernate3-maven-plugin 适合这种情况吗？
感谢您的帮助！
I have a data access layer represented by an Eclipse project. I use Hibernate 3 as persistence framework. So, in this project, I have my annotated entities and the resources used by Hibernate (persistence.xml, XXX.cfg.xml).
My question now is more about how QA and production. I have other projects that use this data access layer. Also, my entities may be modified during the project evolution.
When I release one of these projects to QA, and that the data access layer has been modified (entities modifications), the QA database has to been modified accordingly. And that's the same for production.
What are the best practices for this scenario? I use Maven as build system. Do you think the use of hibernate3-maven-plugin is appropriated for this case?
Thanks for your help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我建议不要在生产/QA 中使用
hibernate3-maven-plugin（使用hbm2ddl.auto），因为它可能会产生不希望的/意外的副作用。我想我在某处读到 Hibernate 创建者自己实际上建议不要在生产中使用hbm2ddl.auto。最好只编写自己的 SQL 补丁来更改数据库架构（它也会得到更好的优化）。
为了跟踪脚本，我们有与软件版本（例如：1.14.1）相对应的目录（在源代码管理中）以及针对特定版本运行的更改的所有 SQL 补丁（我们确保让它们可以重新运行而不会出现任何问题）效果）保留在那里。部署 1.14.1 时，我们运行软件版本所需的脚本（我们还有一个可以自动运行所有所需脚本的脚本，但通常是手动完成的）。
I would recommend against using
hibernate3-maven-plugin(withhbm2ddl.auto) in production/QA because it might have undesired/unexpected side effects. I think I read somewhere that the Hibernate creators themselves actually recommend against usinghbm2ddl.autoin production.It is best to just write your own SQL patches to change the database schema (It will be better optimised as well).
To keep track of the scripts we have directories (in source control) corresponding to a software version (example: 1.14.1) and all SQL patches for changes to run for a specific version (we make sure to keep them re-runnable without side effects) are kept there. When deploying 1.14.1 we run the required scripts for the software release (we also have a script that can automatically run all the required scripts but usually it is done manually).