自動スキーマ移行

このシリーズの最初の部分は利用可能ですEvolutionary Database Design, GraphQL, APIs, and Database Schema Migrations: Part 1 ”.
次の2つの主要な経路があります:私はこのブログのポストとそれ以降のポストに来るhasuraコンソールインターフェイスを使用するグラフィカルな方法で詳細を説明するように、自動手作りの方法です.まず、両方のメソッドがhasura cliツールから始まります.チェックアウトdocumentation , そして、いくつかの余分な情報のために私はポストを書いたHasura CLI Installation & Notes . その前提条件を考慮すると、データモデルのスキーマを起動し、ビルドを開始することができます.

なぜ

このシリーズの最初のポストで議論されるようにEvolutionary Database Design, GraphQL, APIs, and Database Schema Migrations: Part 1 ” 私たちはなぜスキーマ移動の周りに良い実践を設定したいのですか?セットアップと使用の実際の例に入るには、次のデータベーススキーマを作成しました.

このスキーマでは、テーブルとテーブル間の関係がいくつかあります.つの多く、多くの多く、そしていくつかの再帰的な(象の耳)の関係.

開始移行

まず、基本テーブルを作成する必要があります.少なくとも、それは最も簡単な方法です.この最初のスキーママイグレーションでは、これらのテーブルを作成するのに必要なSQLをまとめました.テーブルが作成された後に、関係と追加の要素を追加します.これは、我々の最初の移行を構成します.

CREATE TABLE "Source" (
  "Id" uuid PRIMARY KEY,
  "Stamp" timestamp,
  "Name" text,
  "Uri" text,
  "Details" text
);

CREATE TABLE "SourceNotes" (
  "SourceId" uuid,
  "NotesId" uuid,
  "Details" text,
  "Stamp" timestamp
);

CREATE TABLE "NoteJot" (
  "Id" uuid PRIMARY KEY,
  "Stamp" timestamp,
  "NoteId" uuid,
  "Details" text
);

CREATE TABLE "Activity" (
  "Id" uuid PRIMARY KEY,
  "Stamp" timestamp,
  "Activity" json
);

CREATE TABLE "Connection" (
  "Id" uuid PRIMARY KEY,
  "Stamp" timestamp,
  "ActivityId" uuid,
  "SourceId" uuid
);

CREATE TABLE "Formatter" (
  "Id" uuid PRIMARY KEY,
  "Stamp" timestamp,
  "ConnectionId" uuid,
  "FormatterMap" json
);

CREATE TABLE "Schema" (
  "Id" uuid PRIMARY KEY,
  "Stamp" timestamp,
  "ConnectionId" uuid,
  "SchemaMap" json
);

ここで注意する重要な詳細は、この開始の移行は、我々がしたくない前進するいくつかのことを中断します.ここでは、この最初の移行の問題のいくつかです

移行には多くの部分がある.一般的には、各マイグレーションをテーブルの作成、追加の列、または関連する追加のような特異なステップに保つことです.

この初期化マイグレーションの後に新しいテーブルを作成する場合、テーブルの作成、または列の追加が、その特定のステップでそれらのそれぞれの関係がそれらに追加されるようにマイグレーションを作成したいと思います.

テーブルの順序のsemblanceは、次のステップでは、関係を持っているテーブルとして、密接に注意を払う必要があります、関係を持つテーブルは、どんな関係もそれを描画する前に、それぞれのテーブルが存在する必要があり、それぞれのテーブルのドロップやその他の削除は、その作成の特定の逆順序で行われる必要があります.

しかし、理由は、これが開始スキーマ移行であるので、すぐにその初期のテーブル・スキーマを加えて、そして、これらの中心的なテーブルが存在したあと、より反復的な変更を始めることです.

始める

マイグレーションを作成する前に、設定ファイルをそれぞれのHashura APIとデータベースに初期化し、ポイントする必要があります.この例では、任意のスイッチなしで初期化コマンドを実行し、デフォルトオプションを受け入れます.hasura init
最初のスキーママイグレーションを作成するには、Hasura CLIコマンドを使用します.作成したhasuraディレクトリに移動し、次のように実行します.hasura migrate create "inception"結果は、移行とバージョンの名前を表示します.

今すぐこのフォルダを開く、理想的な視覚的なスタジオコードや好みのあなたの好みのエディタのようなものです.次の画像では、Visual Studioのコードでフォルダーを開き、ポップアップを開きました.作成した移行用のSQLファイル.

この時点でファイルは空と同じように空です.SQLファイル.これは何ですか.SQLとDOWN.SQLファイル?話し合いましょう.

移動は上がる

すべてのマイグレーションでは、データベーススキーマを最新バージョンまで持っていくためのパスがあり、データベーススキーマを以前のバージョンに戻すためのパスが後方にあります.すべての単一の移行は、これらの2つの繰り返しステップを必要とします.hasura CLI使用法から、それは具体的に前後に前後に動く2つのコマンドを含みます.
我々が作成しようとしている移動を進めるか、または実行するために、我々は以下のコマンドを実行します.hasura migrate applyこれは、すべてのアップマイグレーションを実行し、最新のバージョンにデータベーススキーマをもたらします.これらの変更をロールバックし、以前のスキーマ移行バージョンに移動する必要がある場合は、次のコマンドを実行して、1つのバージョンをダウンマイグレーションします.hasura migrate apply --down 1

上向きの移住

ので、これらのステップを取る必要がありますし、手順では、最初の移行を完了するためにSQLで実装する必要があります.上のSQLは、上にコピーします.SQLファイル.

私たちはhasura migrate apply コマンドを今すぐに、代わりにダウンのドロップコマンドを構築しましょう.SQL最初.このように、エラーが発生した場合、すぐにロールバックすることができます.この最初のステップではあまり重要ではありませんが、移行を実行する前に常に上下のステップを構築するのは良い習慣です.
これらのテーブルのどれもこの時点でリレーションシップで作成されないので、DROPコマンドはどんな順序ででもありえます.任意の関係を描画した場合は、これらの関係は、ドロップコマンドリストを必要とします.通常、スキーマの移行を実行すると、この問題には移行しません.マイグレーション自体は複雑な問題にはなりません.唯一の関係、またはテーブルだけが特定の時点で作成されます.

ダウンマイグレーション

各ドロップテーブルのドロップコマンドは以下の通りである.DROP TABLE "Source"; DROP TABLE "SourceNotes"; DROP TABLE "NoteJot" ; DROP TABLE "Activity"; DROP TABLE "Connection"; DROP TABLE "Formatter"; DROP TABLE "Schema";それらの各々を下に加えなさい.SQLファイル.

ポイント&実行

次のステップは、Hasuraインスタンスに対する移行を実行することです.あなた自身のインスタンスを取得し、自分自身を試してみるにはquick 5 minute and 37 second video フリーティアHasuraインスタンスの設定について私は今あなた自身のインスタンスを持っているこの時点で消費します.移行を実行するには、インスタンスのURIが必要です.インスタンスのコンソールに移動し、このイメージに示すようにURIを取得します.

今すぐ設定を開きます.プロジェクトフォルダ構造のルートに位置し、localhost URIを変更し、新しいURIパスを追加します.ではURIのパスを削除します./v1/graphql したがって、私たちは設定でベースURIだけを持っています.YAMLファイル.このように見えるでしょう.

それを保存し、ハサラCLIとの移行を実行します.hasura migrate applyコンソールに移動し、データタブをクリックし、次の表が表示されます.

ロールバックする場合は、次のコマンドを実行します.hasura migrate apply --down 1 つのステップを移動します.もう一度データタブをもう一度見て、ブラウザでリフレッシュをクリックして更新し、テーブルをドロップします.

これらの変更を適用し、このシリーズの次の部分のベースとして使用します.パート3では、私たちの移動を構築するコンソール自体を使用する方法を取得します.我々は、テーブルと他のスキーマ変更の間の若干の関係を加えます.そして、移行プロセスを通して何かをカバーして、Hasura migrationsとのメタデータ・ペアがどのように完全な反復的なversioningと運動をデータベースの変化とhasura APIサーバ自体の変化の間で前後に提供するかについて触れます.

概要

これにより、1回目の移行が完了する.ここで覆われている手順の要約は、たとえ彼らが単純に見える場合でも、ここから行うことができるものの広い広がりを開きます.始めに実装するスキーマを用意しました.次に、そのスキーマ内の各テーブルを作成するために実行する必要があるSQLを次に示します.最後に、スキーママイグレーションプロジェクトフォルダ構造の作成をhasura init , そして、最初の移行フォルダの作成とアップ.SQLとDOWN.SQLファイル.そこから、上下移動ステップに必要なSQLを追加するために一緒に働きました.YAML URIはそれぞれのHashura APIサーバーに、私たちの最初のアップグレードを実行します.私たちは、ちょうど前と後を比較するためにダウンマイグレーションで包まれて、次に、我々は次のポストの準備を残し、アップマイグレーションで終了!