postgresql 如何处理生产中的 Play Framework 2 数据库演变
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/14616005/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to handle Play Framework 2 database evolutions in production
提问by TomahawkPhant
It seems that whenever I change my models, Play Framework asks me to run a script that deletes my entire schema and recreates it. Obviously this won't work for production, so what is the proper way to handle this in production?
似乎每当我更改模型时，Play Framework 都会要求我运行一个脚本来删除我的整个架构并重新创建它。显然这不适用于生产，那么在生产中处理这个问题的正确方法是什么？
Note, I'm using ebean and Postgres, and hosting on heroku.
请注意，我正在使用 ebean 和 Postgres，并在 heroku 上托管。
回答by biesior
Unfortunately Ebeancan create only CREATE DDL(and not UPDATE DDL) (as answered on their group), therefore you need to switch to manual evolutionsASAP.
不幸的是Ebean只能创建CREATE DDL（而不是UPDATE DDL）（如他们小组的回答），因此您需要尽快切换到手动演变。
some rules:
一些规则：
- Always backup your live DB before implementing any changes :)
- ebean plugin recreates whole DDL if it has only
1.sqlevolution created by it - You need to remove two first comments from
1.sqland start to writing own evolutions with next numbers2.sql,3.sqletc. Try to place as many models/fields as possible before switching to manual evolutions. The biggest part will be done automatically by plugin. - manual evolutions should contain
ALTERSto existing tables/columns instead of DROP/CREATE, they should have both:UpsandDownsfor each change. - try to place as many changes in each evolution as possible, it's easier to manage then writing separate evolution for each small change.
- 在实施任何更改之前始终备份您的实时数据库:)
- ebean 插件重新创建整个 DDL，如果它只有
1.sql由它创建的进化 - 您需要从其中删除两个第一条注释，
1.sql然后开始用下一个数字等编写自己的进化。在切换到手动进化之前2.sql，3.sql尝试放置尽可能多的模型/字段。最大的部分将由插件自动完成。 - 手动演化应该包含
ALTERS现有的表/列而不是 DROP/CREATE，它们应该同时包含：Ups和Downs每个更改。 - 尝试在每个演变中放置尽可能多的更改，然后为每个小更改编写单独的演变更容易管理。
De facto sometimes it's just easier to modify DB structure with DB gui, anyway it works mainly for the single developer... when you need to share your code with other developers writing evolutions will be better option.
事实上，有时使用 DB gui 修改 DB 结构更容易，无论如何它主要适用于单个开发人员......当您需要与其他开发人员共享您的代码时，编写演变将是更好的选择。
If after some time you'll add next 'big' portion of new models you can enable temporary auto DDL again and using local git just to copy new parts. Then revert to own revolution and paste new parts generated by Ebean plugin.
如果一段时间后您将添加新模型的下一个“大”部分，您可以再次启用临时自动 DDL 并使用本地 git 来复制新部分。然后恢复到自己的革命并粘贴由 Ebean 插件生成的新部分。
回答by JBT
Biesior basically summed it up quite well. However, as a beginner in Play, I find that a bit more clarification with a concrete example might be helpful.
Biesior基本上总结得很好。但是，作为 Play 的初学者，我发现通过具体示例进行更多说明可能会有所帮助。
First, the following example is for Java.
首先，以下示例适用于 Java。
Suppose you added a new field
假设您添加了一个新字段
public String dum_str;
in your model Dum. Then, you will need a 2.sqlunder conf/evolutions/like this:
在你的模型 Dum 中。然后，您将需要一个像这样的2.sql下conf/evolutions/：
# --- !Ups
ALTER TABLE dum ADD COLUMN dum_str VARCHAR(255);
# --- !Downs
ALTER TABLE dum DROP dum_str;
I hope this would be helpful.
我希望这会有所帮助。
