将来を見据えたウェブ・アプリケーションの構築:The Codestのエキスパート・チームによる洞察
The Codestが、最先端技術を駆使してスケーラブルでインタラクティブなウェブアプリケーションを作成し、あらゆるプラットフォームでシームレスなユーザー体験を提供することにどのように秀でているかをご覧ください。The Codestの専門知識がどのようにデジタルトランスフォーメーションとビジネス...
アプリの開発は、新しい機能の実装やパッチの適用だけを意味するわけではない。時には変更を元に戻し、プロジェクトの前の段階に戻らなければならないこともある。複数のブランチにまたがって作業しているときに頻繁に発生する問題は、データベース構造の適切なバージョンを維持することです。railsを使用するプログラマーは、自由に使える既製のソリューションを持っています。これらのソリューションは、データベースの変更の実装と制御をサポートします。ここでは、マイグレーションがどのように機能し、どのような可能性をもたらすかについては説明しません。
アプリのデータベースレイヤーは独立した存在であり、マイグレーションによってのみ制御される。新しいマイグレーションを作成する際には、データベース構造の計画された変換を可逆的なものにすることを忘れないでください。もちろん、極端なケースでは 不可逆マイグレーション
での ダウン メソッドを使用する。これは、マイグレーションが元に戻せないという事実も教えてくれる。テーブル、カラム、インデックスの作成、変更、削除です。削除と変更の操作は、変更に対して最も敏感である。なぜでしょうか?次のようなシナリオを考えてみましょう。私たちはmasterブランチで作業しています。現在、テーブルがひとつあります:
class CreateArticles < ActiveRecord::Migration
def change
create_table :articles do |t|
t.string :名前
t.text :説明
t.string :status, null: false
t.タイムスタンプ null: false
終了
終了
終了
私たちの 記事
モデルにはこのようなバリデーションがある。 名称, 記述 そして ステータス の属性を持つ。
class Article < ActiveRecord::Base
validates :name, presence: true
validates :description, presence: true
validates :status, presence: true
終了
私たちは、このような変更を実施している。 記事 テーブル 特徴 開発ブランチを削除し ステータス コラム
クラス RemoveStatusColumnFromArticles < ActiveRecord::Migration
def change
remove_column :articles, :status, :string
終了
終了
我々は移行を実行する:
$ [example/feature]: bundle exec rake db:migrate
-- remove_column(:articles, :status, :string)
-> 0.0717s
データベースのスキーマが変更される:
diff --git a/db/schema.rb b/db/schema.rb
index 2a100a9..76438c1 100644 --- a/db/schema.rb +++ b/db/schema.rb @@ -11,14 +11,13 @@ #
このファイルをバージョン管理システムにチェックインすることを強く推奨する。
-ActiveRecord::Schema.define(version: 20150605120350) do
+ActiveRecord::Schema.define(version: 20150605120955) do
createtable "articles", force: :cascade do |t|.
t.string "名前"
t.string "description"
- t.string "status", null: false t.datetime "createdat", null: false
t.datetime "updated_at", null: false
終了
終了
次に、変更を 特徴 ブランチに切り替える。この問題をシミュレートするために、現在のブランチをmasterに切り替えます。マイグレーションによって基本構造が変更され ステータス 列の 特徴 ブランチ。次のコマンドを使ってみよう:
Article.create!(name: "Kaboom", description: "Loremipsum...", status: "active")
上記を実行するとどうなるか コード?エラーです: ActiveRecord::UnknownAttributeError: Article の属性 'status' が不明です。
これはデータベースの構造バージョンに互換性がないためです。ブランチをマスターに変更する前に、マイグレーションをロールバックする必要があります。 ステータス 列から 記事 テーブル
ブランチを切り替える前に、移行をロールバックする必要があるかどうかを確認するためには、どうすればいいでしょうか?バージョン管理システム(ここでは ギット)役に立つエイリアスを作ることで、自分たちの仕事をチェックすることができる:
~/.gitconfig
[エイリアス]
migrations = "!f() { git diff --name-only $1..$2 db/migrate | tr -d '[A-Za-z/_.]'; }; f".
を実行する。 gitマイグレーション・マスター機能
コマンドを実行すると、移行バージョンのリストが表示される。 特徴 で見つけることができない。 マスター.
$ [example/feature]: git migrations マスター機能
20150605120955
この情報のおかげで、マスターに切り替える前にデータベース構造で行われた変更を簡単にロールバックすることができる。
$ [example/feature]: bundle exec rake db:migrate:down VERSION=20150605120955
-- add_column(:articles, :status, :string)
-> 0.0009s
マイグレーションをロールバックした後にすべきもう一つのことは、データベーススキーマのステータスをリストアすることである。
$ [example/feature]: git status
ブランチ機能
コミット用にステージされていない変更:
(コミットする内容を更新するには "git add ..." を使う)
(作業ディレクトリの変更を破棄するには "git checkout -- ..." を使う)
変更: db/schema.rb
コミットに変更は追加されません("git add" や "git commit -a" を使用します)。
$ [example/feature]: git checkout db/schema.rb
$ [例/機能]: git ステータス
ブランチ機能
コミットするものがありません。
これで簡単に マスター ブランチだ。
この例題は複雑な問題ではないが、データベースの構造を維持することがいかに重要かを理解するのに役立つだろう。