データベースの移行-ライブラリの概要と使用法

お読みいただいたかもしれませんが 、CodeIgniterの新しいバージョンが最近リリースされました。その革新の1つが移行ライブラリです。 その主要な開発者の1人であるPhil Sturgeonは、 Railsのデータベースバージョン管理の利便性に非常に触発されたため、CodeIgniterのこのようなメソッドの類似物を作成することにしました。

この記事から、移行の一般的な考え方を理解し、それらを作成する方法も学びます。 第2部では、アプリケーションに簡単に統合できることを確認します。

この記事は初心者のCodeIgniterユーザーには役立ちますが、上級の同僚がこの素晴らしいライブラリについて学び、自分自身のために新しいことを学ぶことを望んでいます。



とりわけ、このライブラリはまったく複雑ではなく、必要に応じて他のプラットフォームに実装することは難しくありません！

ライブラリの概要

移行ライブラリを使用すると、データベースのすべての変更をアプリケーションに保存し、必要に応じてそれらをロールバックまたはロールバックできます。 チームでの開発に便利です。コードを機能させるためにデータベースで変更する必要があるものを同僚に説明したり、サイトの新しいバージョンをバトルサーバーにアップロードしたりする必要はありません。 または、最悪の場合、どこかでめちゃくちゃになった場合、いつでも古いバージョンにすぐにロールバックできます。



ライブラリがどのように機能するかを一般的な用語で理解するには、次の原始的なシナリオを検討してください。

0. 最初のベース（またバージョン0）を持つアプリケーションの0バージョンがあるとします 。

1.開発中、新しい機能（ニュースレターサブスクリプションシステムなど）を実装するには、アプリケーションコードだけでなくデータベース構造も変更する必要があることを理解しています。

2. これを行うには、このバージョンのコードのデータベースバージョンが1になるように構成で指定し、新しいコードとともに001移行を作成し、アップグレードとデータベースダウングレードの両方のアクションを示します（アプリケーションバージョンをロールバックする必要がある場合） ）

3.次に、ローリング更新のためのある種のメカニズムを実装します。管理パネルのページ、CLIを使用したソリューション、またはバージョン管理システムからダウンロードする際の完全自動更新です。

4.新しいプロジェクトコードをサイトにアップロードし、目的のバージョンへの移行を開始します。



では、事前に3つのバージョンでアプリケーションを更新する必要があることを想像してください。または、テストサーバーで、数か月前に作成されたバージョンがどのように実装されたかを確認してください。 簡単で、コードを変更するだけで、目的のバージョンのデータベースに移行します（たとえば、4番目から1番目、3番目、2番目に徐々に移行し、1番目のバージョンがロールバックします）。



あなたは私のようなこの機会に触発され、それを試してみたいですか？ これ以上簡単なことはありません！

実用化

実際のところ、ライブラリは完全に使いやすく、プロジェクトに実装するには、かなりの数行のコードを追加する必要があります。

移行を作成するプロセス全体に10分かかることはありませんが、同じプロジェクトで作業しているあなたと同僚をかなり節約できます。

クラスMY_Migrationを作成します

そのため、まず最初に、 Migrationクラスを拡張するために少し申請する必要があります 。

なんで？ すべてが非常に単純です。デフォルトでは、このクラスはデータベースとコードのどのバージョンが最新であるかをレポートできません。また、コード全体でこれらのチェックを実装することは完全に正しいわけではありません。

これを行うには、CodeIgniterで使用されている標準のクラス拡張方法を使用します。数十行のコードを含むファイル％site_path％/ application / libraries / MY_Migration.phpを作成します。

このクラスは、先祖の実装にさらに2つのパブリックメソッドを追加します。

/** * Wrapper function for the protected _get_version. * Get's the database current version * * @access public * @return integer Current DB Migration version */ public function get_db_version() { return parent::_get_version(); } /** * Retrieves current file system version * * @access public * @return integer Current file system Migration version */ public function get_fs_version() { return $this->_migration_version; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

注：以下では、コードのリストを短縮して、記事の最後にあるチュートリアルで使用されるすべてのファイルへのリンクを示します。



ご覧のとおり、関数はデータベースバージョンを取得するためのprotectedメソッドと、 保護された$ _migration_versionプロパティの単なるラッパーであり、 カプセル化の使用を非常に明確に示しています。

また、重要な点に注意することをお勧めします。元のMigrationクラスには制限があり、 そのコンストラクタは親クラスが初期化されたときにのみ実行されるためです。

したがって、アプリケーションが正しく動作し、元の代わりにMY_Migrationを自動的に初期化するには、親クラスのコンストラクターを複製し、その行41の条件を変更する必要があります。

  public function __construct($config = array()) { # Only run this constructor on main library load if (get_parent_class($this) !== FALSE) { return; } ### Other code here... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

に

  public function __construct($config = array()) { # Only run this constructor on main library load if (get_parent_class($this) !== FALSE && get_class($this)!='MY_Migration') { return; } ### Other code here... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

移行を作成する

基本クラスを拡張することにより、問題は小さくなります。 ライブラリがデータベースへの変更をロールバックまたはロールバックできるようにするには、 Migration下位クラス（この場合はMY_Migration ）を含む移行ファイルを作成する必要があります。

これは最初の移行であるため、次のファイルを作成します： ％site_path％/ application / migrations / 001_add_messages.php 、upおよびdown関数を含みます：

 <?php defined('BASEPATH') OR exit('No direct script access allowed'); class Migration_Add_messages extends MY_Migration { public function up() { $this->db->query(" CREATE TABLE IF NOT EXISTS `email_list` ( `list_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT, `email` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL ) ENGINE=MyISAM;"); } public function down() { $this->db->query("DROP TABLE IF EXISTS `email_list`"); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

移行のあるファイルは、データベースを変換するバージョンの3タスクのデジタルシリアル番号の先頭に含まれ、ファイルに含まれるクラスはファイル名と呼ばれ、バージョン番号の代わりにMigration_であることに注意してください。

設定を編集

最後に、移行を行うには、 ％site_path％/ application / config / migration.phpファイルの設定を少し調整して有効にする必要があります。コードの正しい操作に必要なデータベースのパスとバージョンが指定されているかどうかを確認します（標準のコメントはリスト）：

  $config['migration_enabled'] = TRUE; $config['migration_version'] = 1; $config['migration_path'] = APPPATH . 'migrations/';
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初のバージョンを示したことに注意してください。これは、メーリングリストの機能を既に実行していることを意味します。

まとめ

したがって、ライブラリの使いやすさをわずかに改善し、その機能を拡張し、元のクラスの継承についてコンストラクタをチェックすることに関連する落とし穴を回避し、移行の作成方法も学びました。

ご覧のとおり、移行を作成するのに複雑なことは何もありません。また、大幅な時間を節約できます。 さらに、現在のプロジェクトでの実装も問題を引き起こすことはありません。 ちなみに、ご紹介は私の2番目の記事にささげられますが、これは近い将来登場します。



完全なソースでアーカイブをダウンロードする



パート2：データベースの移行-アプリケーションとの統合



PS： CodeIgniterブログに公開するのに十分なカルマがないので、今のところ一般的なphpブログを公開しています

UPD：良い匿名が小さなカルマを注ぎ、CodeIgniterブログに転送しました