intelworx/dbvc

此包最新版本(dev-master)没有可用的许可证信息。

DBVC:数据库版本控制,受http://dbv.vizuina.com/和FlywayDB for Java启发。

dev-master 2015-06-22 08:25 UTC

This package is auto-updated.

Last update: 2024-09-19 09:16:08 UTC


README

DBVC 受http://dbv.vizuina.com/启发,它使用了DBV的一些核心类。然而,与DBV不同,DBVC

  • 被设计为在CLI上工作
  • 被设计为仅以正向模式应用修订,但也可以按顺序外工作
  • 被设计为类似Flyway DB迁移(http://flywaydb.org

DBVC是用PHP编写的,因此它可以自由地集成到您的PHP脚本中,尽管您也可以轻松地将其用于其他项目。

DBMigration可以在3种模式下使用,所有这些模式都在DBMigrationMode类中定义

  1. Dry-run,指定脚本仅显示将要执行的查询列表。
  2. 交互模式,将列出要应用的所有更改,并在应用更改之前要求您确认。这是迁移.php中使用的模式。
  3. 非交互模式,在没有任何人为干预的情况下运行DB迁移。

使用DBMigration

可以使用以下命令运行迁移脚本

#!php

require_once /path/to/dbvc/dbvc.php;

use intelworx\dbvc\DBMigration;
use intelworx\dbvc\DBMigrationMode;

$dbConfig = array(
	//this is the only adapter implemented for now
    'adapter' => 'MySQL', 
	//the database host
    'host' => 'localhost',
	//database port
    'port' => 3306,
	//database username
    'username' => 'root',
	//database password
    'password' => '',
	//database on which to perform migration
    'database' => 'test',
);

$migration = new DBMigration('/path/to/revisions_dir', $dbConfig);

//mode to run migration
$mode = DBMigrationMode::INTERACTIVE;

//version to start from, useful, when you wish to jump versions
$startVersion = 0;

$outOfOrder = true;

//run migration, throws DBMigrationException on error.
$migration->runMigration($mode, $startVersion, $outOfOrder);

术语定义

修订文件:包含对数据库进行更改的SQL文件,它可以包含尽可能多的查询。请参阅下一节关于修订文件命名的说明。

修订目录:这是一个存储所有修订的文件夹。

迁移表:这是一个数据库表,用作DBVC的存储,其名称通常是`dbvc__schema_version`,它用于跟踪已应用于架构的修订文件。

架构:数据库的另一个名称

不良修订文件:这是一个包含您希望跳过数据库中修订版本号的文件。此文件应每行只有一个版本号,并应保存为`/path/to/revisions_dir/bad_revisions.txt`。

指定架构版本的指南

本节指定架构修订的指南,请仔细阅读。

修订文件命名

修订文件应按以下格式命名:{version_number}_version_description.sql,并应保存在修订文件夹中。version_number应该是顺序的且唯一的。

示例:如果您更改数据库表中的用户以添加一个新列,例如email2,并且最后一个文件是10_a_chnge.sql,则迁移文件应保存为`/path/to/revisions_dir/11_added_email2_to_users.sql`。

将更改应用到数据库

为了防止错误,建议您不要使用任何MySQL客户端将更改应用到数据库,而只应使用此脚本更改数据库对象的架构。您应使用客户端生成更改查询,将查询放入修订文件中,然后运行迁移脚本,这样您就可以确保已成功更新跟踪应用的迁移的迁移文件。

版本冲突

在创建版本文件之前,建议首先从上游拉取,以便获取最新的数据库更改,这可以节省您处理重复版本ID的压力。如果出现重复版本ID,则已存在于仓库中的版本获胜,拉取者应撤销其修订文件所做的更改,并从迁移存储表中删除更改。

因此,如果在之前的示例中,您拉取并发现已存在另一个名为 /dbvc/revisions/default/11_another_change.sql 的文件,那么您应该执行以下操作:如果您尚未运行迁移脚本,则将迁移文件重命名为 12_added_email2_to_users.sql,这也假设在您拉取时没有版本 11。然后运行迁移脚本。

建议您在应用迁移脚本后立即将其推送到上游。如果您确信所做的更改不会破坏现有代码,则可以仅将修订文件推送到上游。如果您的修订将破坏现有代码,则应在准备就绪时推送整个仓库,请注意,您等待的时间越长,遇到版本冲突的可能性就越大。

顺序迁移

当此选项设置为 true 时,所有尚未应用的所有修订都将被应用,这改变了 DBVC 正常工作的方式,并且具有使用功能分支的团队可以轻松合并其工作并应用所有更改的优点,使用顺序机制。在这种情况下,建议每个分支都有自己的修订范围,例如,master 分支为 0 - 1000,功能 x 为 1001 - 1100,依此类推。

撤销更改

MySQL 和一些其他数据库管理系统不支持 DDL 查询的回滚,因此对数据库结构的更改无法自动撤销。如果您在一个修订中进行了更改,并且发现这不是您想要的更改,那么您应该创建另一个修订文件来撤销该更改。

处理行结束符

DBVC 对行结束格式的变化免疫,文件校验和检查器将在检查文件是否仍与存储的修订匹配时假设所有可能的行结束格式。请注意,这仅涵盖以下行结束符:CRLFCRLF

许可

MIT 许可证 (MIT)