|
但愿我能很好地表明这一点.
我有一个Laravel应用措施,已经出产了一分钟.以是,我有一堆迁徙文件,有许多变革.我想整合这些迁徙文件而不会丢失数据库.
我以为这会起浸染的方法：
>将全部出产表迁徙到所需状态.
>将全部迁徙文件归并到所需的起码文件数中.
>破除迁徙表.
>运行迁徙或添补迁徙表.
我想这样做的部门缘故起因是由于我但愿果真一些处事提供商,并尽也许行使最干净的迁徙配置.
坚苦的版本也许是：
>备份或一再表.
>运行迁徙.
>编写并运行剧本以添补“干净”表.
只是但愿有一种比这更简朴的要领.
编辑(来自评述)：我有一个出产数据库,个中包括约莫50个迁徙文件 – 一些小的变动,一些大的变动.假如我归并,所需的迁徙数目约莫为12阁下.我想整合迁徙文件,但如故可以或许执行迁徙：出产回滚 – 不是我想要的.
最佳谜底
颠末屡次太过计划和过于智慧的办理方案实行后,我以为以下是办理题目的可行要领.
TL;博士：
>迁徙任何一方的Bookend迁徙,无需构建模式.
>更新项目.
>迁徙.
>删除书挡和全部早年的迁徙.
>从迁徙表中删除记录.
第一个书挡重定名受影响的表.第二个书挡将数据从重定名的表复制到新表,然后删除重定名的表.
留意：你可以在书挡内做任何你喜好的工作,这只是最低限度.
那么,让我们说你的迁徙如下：
> 2017_09_05_000000_create_some_table.php
> 2017_09_05_000001_add_field_x_to_some_table.php
> 2017_09_05_000002_add_field_y_to_some_table.php
> 2017_09_05_000003_add_field_z_to_some_table.php
我们将建设另一个迁徙：
> 2017_09_05_000004_pre_refresh.php
我们将按照我们此刻的常识建设另一个迁徙：
> 2017_09_05_000005_create_some_table.php
我们将建设最后一个书挡,举办数据迁徙：
> 2017_09_05_000006_post_refresh.php
前四次迁徙将不会运行,由于它们已经存在.
/** 2017_09_05_000004_pre_refresh.php */
class PreRefresh extends Migration
{
public function up()
{
$prefix = 'zz_';
$tablesToRename = [
'foos','bars'
];
foreach($tablesToRename as $table) {
Schema::rename($table,$prefix . $table);
}
}
}
不必要降落,由于这是一次性买卖营业.这将起首运行,这将导致重定名数组中列出的全部表.然后将运行归并(优化)迁徙.
/** 2017_09_05_000006_post_refresh.php */
class PostRefresh extends Migration
{
public function up()
{
// Do what you need to do.
// If you cannot use your models,just use DB::table() commands.
$foos = DB::table('zz_foos')->get();
foreach ($foos as $foo) {
DB::table('foo')->insert([
'id' => $foo->id,'created_at' => $foo->created_at,'updated_at' => $foo->updated_at
]);
}
$bars = DB::table('zz_bars')->get();
foreach ($bars as $bar) {
DB::table('bar')->insert([
'id' => $bar->id,'created_at' => $bar->created_at,'updated_at' => $bar->updated_at,'foo_id' => $bar->foo_id
]);
}
// Tear down.
$prefix = 'zz_';
$tablesToRename = [
'foo','bar'
];
foreach ($tablesToRename as $table) {
DB::statement('SET FOREIGN_KEY_CHECKS=0');
Schema::dropIfExists($prefix . $table);
DB::statement('SET FOREIGN_KEY_CHECKS=1');
}
}
}
运行此操纵后,您可以从pre_refresh和之前删除全部迁徙.以及post_refresh.然后,您可以进入迁徙表并删除这些迁徙的条目.
删除条目并不是完全须要的,但假如您迁徙：rollback,您将收到错误动静,指出无法找到迁徙.
留意事项
>假如架构不是模块化的,那么它也许很是贫困.可是,假如您已将代码疏散为处事,那么它好像更轻易一些.
>迁徙进程中的Laravel错误处理赏罚和动静很是有限;以是,调试也许很坚苦.
>凶猛提议从应用措施/处事中最不变的表开始.另外,从您的应用措施的基本开始也也许是有益的.
留意：当我在出产中现实执行此操纵时,不只仅是我的当地(一遍又一遍),假如没有更好的谜底,那么我会接管这一点.
留意事项
假如您通过审慎的迁徙将应用措施解析为处事提供商,则可以在运行迁徙时在/ config / app中注释掉处事提供商.这样,您可觉得此刻基线的处事建设批处理赏罚.因此,假设您有以下迁徙,个中每个字母代表一个迁徙,每个一再的字母代表沟通的处事：
> A.
> B.
> C.
> A.
> C.
> B.
> A.
归并处事A后：
> B.
> C.
> C.
> B.
> A.
归并B后：
> C.
> C.
> A.
> B.
归并C后：
> A.
> B.
> C.
更新
迄今已将54次迁徙降至27次.我乃至从大型up()和down()要领中取出了一些Schema变动,并使它们成为单独的迁徙.这里好的副浸染是批次.我从基表开始迁徙,个中支持其他全部内容;因此,回滚更多的是处事.
（编辑：湖南网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
