バックエンドアプリケーションは、PostgreSQL、SQLite、MariaDBなどのさまざまなデータベースで動作します。開発者は、データベースの状態を簡単かつ安全に変更する機能を実装するという課題に直面しています。データベースの構造とデータ自体の両方を、アプリケーションのあるバージョンから別のバージョンに変更する必要があります。





私の講演では、移行を管理するための実績のあるツールであるAlembicを使用した経験を共有しました。 Alembicを選択する理由、それを使用して移行を準備する方法、それらを（自動または手動で）実行する方法、不可逆的な変更の問題を解決する方法、移行をテストする理由、テストで明らかにできる問題、およびそれらを実装する方法-私はこれらすべての質問に答えようとしました。同時に、Alembicでの移行作業を簡単で楽しいものにするいくつかのライフハックを共有しました。



レポートの日以降、GitHubのコードがわずかに更新され、さらに多くの例があります。スライドに表示されているとおりにコードを確認したい場合は、その時点からのコミットへのリンクを次に示します。



- こんにちは！私の名前はアレクサンダーです。エダディルで働いています。今日は、私たちがどのように移行と共存し、どのように移行と共存できるかをお話ししたいと思います。おそらくこれはあなたがより簡単に暮らすのに役立つでしょう。

移行とは何ですか？

始める前に、一般的な移行について説明する価値があります。たとえば、アプリケーションがあり、それが機能するようにいくつかのタブレットを作成し、それらにアクセスします。次に、何かが変更された新しいバージョンをロールアウトします。最初のプレートが変更され、2番目のプレートは変更されておらず、3番目のプレートは以前はありませんでしたが、表示されました。







次に、アプリケーションの新しいバージョンが表示され、一部のプレートが削除され、残りのプレートには何も起こりません。それは何ですか？これが移行で表現できる状態と言えます。ある状態から別の状態に移行するとき、これはアップグレードであり、戻りたいときはダウングレードです。



移行とは何ですか？







一方では、これはデータベースの状態を変更するコードです。一方、これは私たちが開始するプロセスです。







移行にはどのようなプロパティが必要ですか？アプリケーションのバージョンで切り替える状態がアトミックであることが重要です。たとえば、2つのテーブルが必要なのに、1つしか表示されない場合、これは本番環境であまり良い結果をもたらさない可能性があります。



変更をロールバックできることが重要です。新しいバージョンをロールアウトした場合、それは離陸せず、ロールバックできず、通常、すべてがひどく終了します。



また、バージョンを順番に並べて、ロールする方法を連鎖させることも重要です。

ツール

これらの移行をどのように実装できますか？







頭に浮かぶ最初のアイデア：さて、移行はSQLです。クエリを使用してSQLファイルを作成してみませんか。私たちの生活を楽にすることができるいくつかのモジュールがあります。







内部で何が起こっているかを見ると、確かにいくつかの要求があります。それはCREATETABLE、ALTER、その他何でもかまいません。 downgrade_v1.sqlファイルでは、すべてキャンセルします。







なぜあなたはこれをすべきではないのですか？主にあなたがあなたの手でそれをする必要があるからです。 beginを記述してから、変更をコミットすることを忘れないでください。コードを書くときは、すべての依存関係と何をどの順序で行うかを覚えておく必要があります。これはかなり日常的で、困難で時間のかかる仕事です。



誤って間違ったファイルを起動することに対する保護はありません。すべてのファイルを手動で実行する必要があります。 15回の移行がある場合、それは簡単ではありません。いくつかのpsqlを15回呼び出す必要がありますが、それほどクールではありません。



最も重要なことは、データベースがどのような状態にあるかがわからないことです。ダウンロードしたファイルとダウンロードしなかったファイルをどこかに（紙に、どこかに）書き留める必要があります。あまり良くないですね。yoyo-migrations







モジュールがあります。最も一般的なデータベースをサポートし、生​​のクエリを使用します。 彼が私たちに提供するものを見ると、次のようになります。同じSQLが表示されます。 yoyoライブラリをインポートするPythonコードが右側にすでにあります。















したがって、正確に自動的に移行を開始できます。つまり、新しい移行を作成してチェーンに追加するコマンドがあり、そこでSQLコードを記述できます。コマンドを使用して、1つ以上の移行を適用したり、ロールバックしたりできます。これはすでに一歩前進しています。







さらに、データベースで実行したリクエスト、起動したファイル、何かが発生した場合にロールバックする必要がある場所を紙に書く必要がなくなります。ある種の絶対確実な保護があります。データベースの他の2つの状態間の移行のために、他の目的で設計された移行を開始できなくなります。非常に大きなプラス：これは、個別のトランザクションで各移行を実行します。これはまたそのような保証を与えます。







欠点は明らかです。あなたはまだ生のSQLを持っています。たとえば、Pythonでロジックが広大な大規模なデータを生成している場合、SQLしかないため、それを使用することはできません。



また、自動化できない日常業務がたくさんあります。テーブル間のすべての関係（どこかに書き込むことができるものと、まだ不可能なもの）を追跡する必要があります。一般に、非常に明らかな欠点があります。



注意を払う価値があり、今日の話全体が取り上げられているもう1つのモジュールは、Alembicです。







それはyoyoと同じもの、そしてもっとたくさんあります。移行を監視して作成する方法を知っているだけでなく、非常に複雑なビジネスロジックを記述したり、データ生成全体、Pythonの任意の機能を接続したりすることもできます。必要に応じて、データをプルして内部で処理します。したくない場合は、する必要はありません。



ほとんどの場合、彼は自動的にコードを書くことができます。もちろん、常にではありませんが、手でたくさん書く必要があった後は、良いプラスのように聞こえます。



彼はたくさんのクールなものを持っています。たとえば、SQLiteはALTERTABLEを完全にはサポートしていません。また、Alembicには、これを数行で簡単にバイパスできる機能があり、考えることすらありません。



前のスライドには、Django-migrationsモジュールがありました。これは、移行に非常に適したモジュールでもあります。その原理は、機能的にはAlembicに匹敵します。唯一の違いは、フレームワーク固有であり、Alembicはそうではないことです。

SQLAlchemy

AlembicはSQLAlchemyに基づいているため、SQLAlchemyを少し実行して、それが何であるかを覚えたり調べたりすることをお勧めします。







これまで、生のクエリについて見てきました。生のクエリは悪くありません。これはとても良いことです。負荷の高いアプリケーションがある場合、これがまさに必要なものかもしれません。一部のオブジェクトをある種のクエリに変換する時間を無駄にする必要はありません。



追加のライブラリは必要ありません。あなたはただドライバーを取るだけで、それだけです、それは機能します。しかし、たとえば、複雑なクエリを作成する場合、それはそれほど簡単ではありません。まあ、定数を取得して起動し、大きな複数行のコードを作成することができます。しかし、そのような要求が10〜20ある場合、すでに読むのは非常に困難です。そうすると、それらを再利用することはできません。あなたはたくさんのテキストと、もちろん、文字列、f文字列などを操作するための関数を持っていますが、これはすでにあまり良く聞こえません。それらは読みにくいです。



たとえば、クエリや複雑な構造も必要なクラスがある場合、インデントは非常に苦痛です。生の移行を行いたい場合、何かを使用している場所を見つける唯一の方法は、grepを使用することです。また、動的クエリ用の動的ツールもありません。



たとえば、非常に簡単なタスクです。エンティティがあり、1つのプレートに15のフィールドがあります。 PATCHリクエストを行いたい。とてもシンプルに思えます。生のクエリでこれを書いてみてください。見た目はあまり良くなく、プルリクエストが承認される可能性は低いです。







これに代わるものがあります-クエリビルダー。クエリをPythonのオブジェクトとして表すことができるため、確かに欠点があります。



便宜上、リクエストの生成時間とメモリの両方を支払う必要があります。しかし、プラスがあります。大規模で複雑なアプリケーションを作成する場合は、抽象化が必要です。クエリビルダーは、これらの抽象化を提供できます。これらのクエリは分解できます。これがどのように行われるかについては、少し後で説明します。それらは、ビジネスロジックに関連付けられたフレンドリ名とすでに呼ばれている関数で再利用、拡張、またはラップすることができます。



動的クエリの作成は非常に簡単です。何かを変更する必要がある場合は、移行を記述してください。コードの統計分析で十分です。とても便利です。



とにかくSQLAlchemyはなぜですか？なぜ立ち寄る価値があるのですか？







これは、移行だけでなく、一般的な問題です。 Alembicがある場合、SQLAlchemyは同期ドライバーだけで機能するわけではないため、スタック全体を一度に使用するのが理にかなっています。つまり、Djangoは非常に優れたツールですが、Alchemyは、たとえばasyncpgやaiopgで使用できます。 Selivanovが言ったように、Asyncpgを使用すると、1秒あたり100万行を読み取ることができます。データベースから読み取って、Pythonに転送します。もちろん、SQLAlchemyを使用すると、少し少なくなり、オーバーヘッドが発生します。とにかく。



SQLAlchemyには、操作方法を知っている信じられないほどの数のドライバーがあります。 OracleとPostgreSQLがあり、すべての好みと色に対応しています。さらに、それらはすでに箱から出されており、別のものが必要な場合は、最近調べたところ、Elasticsearchもあります。確かに、読むためだけですが、わかりますか？ -SQLAlchemyのElasticsearch。



非常に優れたドキュメント、大規模なコミュニティがあります。たくさんのライブラリがあります。そして重要なことに、それはあなたにフレームワークとライブラリを指示しません。うまく行う必要のある狭いタスクを実行している場合、それはツールになる可能性があります。



それで、それは何で構成されていますか？







今日一緒に働く主要な実体をここに持ってきました。これらはテーブルです。リクエストを作成するには、Alchemyにそれが何であるかと私たちが何を扱っているかを伝える必要があります。次はMetaDataレジストリです。エンジンは、データベースに接続し、Dialectを介してデータベースと通信するものです。



それが何であるかを詳しく見てみましょう。







MetaDataは一種のオブジェクトであり、コンテナであり、テーブル、インデックス、および一般に、所有しているすべてのエンティティを追加します。これは、一方では、記述したコードに基づいてデータベースをどのように表示するかを反映するオブジェクトです。一方、MetaDataはデータベースにアクセスして、実際に存在するもののスナップショットを取得し、このオブジェクトモデル自体を構築できます。



また、MetaDataオブジェクトには非常に興味深い機能が1つあります。これにより、インデックスと制約のデフォルトの命名テンプレートを定義できます。 PostgreSQL、MySQL、MariaDBなど、すべてのデータベースにはインデックスの呼び出し方法に関する独自のビジョンがあるため、移行を作成する場合、これは非常に重要です。



一部の開発者は、独自のビジョンも持っています。また、SQLAlchemyを使用すると、標準を一度だけ設定して、その動作をすべて確認できます。 SQLiteとPostgreSQLの両方で動作する必要のあるプロジェクトを開発する必要がありました。とても便利でした。







次のようになります。SQLAlchemyからMetaDataオブジェクトをインポートし、作成するときに、naming_conventionパラメーターを使用してテンプレートを指定します。このパラメーターのキーは、インデックスと制約のタイプを指定します。ix-通常のインデックス、uq-一意のインデックス、fk-外部キー、pk-プライマリキー。



Naming_conventionパラメーターの値では、インデックスタイプ/制約（ix / uq / fkなど）とテーブル名で構成されるパターンを下線で区切って指定できます。一部のテンプレートでは、すべての列を一覧表示することもできます。たとえば、プライマリキーに対してこれを行う必要はなく、テーブル名を指定するだけで済みます。



新しいプロジェクトの作成を開始するときは、名前付けテンプレートを一度追加すると忘れてしまいます。それ以降、すべての移行は同じ名前のインデックスと制約で生成されています。



これは別の理由で重要です。オブジェクトモデルでこのインデックスが不要になったと判断して削除すると、Alembicはそれが何と呼ばれるかを認識し、移行を正しく生成します。これは、すべてが正常に機能するという信頼性の一定の保証です。



必ず遭遇するもう1つの非常に重要なエンティティは、テーブルです。これは、テーブルに含まれる内容を説明するオブジェクトです。







テーブルには名前とデータタイプの列があり、MetaDataは説明するすべてのレジストリであるため、必然的にMetaDataレジストリを参照します。また、データタイプの列があります。



私たちが説明したことのおかげで、SQLAlchemyは今では多くのことを知ることができます。ここで外部キーを指定した場合でも、彼女はテーブルが互いにどのように接続されているかを知っています。そして、彼女は何かをする必要がある順序を知っているでしょう。







SQLAlchemyにはEngineもあります。重要：リクエストについて述べたことは個別に使用でき、エンジンは個別に使用できます。そして、あなたはすべてを一緒に使うことができます、誰も禁じません。つまり、Engineはサーバーに直接接続する方法を知っており、まったく同じインターフェイスを提供します。いいえ、もちろん、さまざまなドライバーがDBAPIに準拠しようとします。推奨を行う、PythonのPEPがあります。しかし、Engineはすべてのデータベースに対してまったく同じインターフェースを提供し、非常に便利です。







最後の主要なマイルストーンはDialectです。これは、エンジンがさまざまなデータベースと通信する方法です。ここには、さまざまな言語、さまざまな人々、さまざまな方言があります。



これが何のためにあるのか見てみましょう。







これは通常のインサートがどのように見えるかです。 IDと電子メールフィールドがあった、前に説明したテーブルに新しい行を追加する場合は、ここで電子メールを指定し、挿入を実行して、挿入したすべてのものをすぐに返します。



たくさんの行を追加したい場合はどうなりますか？問題ない。







ここで口述のリストを転送するだけです。いくつかの超シンプルなペンの完璧なコードのように見えます。データが入り、ある種の検証とJSONスキーマに合格し、それだけでデータベースに入りました。超簡単。



一部のクエリは非常に複雑です。リクエストを印刷して表示できる場合もあれば、コンパイルする必要がある場合もあります。これは難しいことではありません。 Alchemyを使用すると、これらすべてを実行できます。この場合、リクエストをコンパイルしました。実際にデータベースに何が送信されるかを確認できます。







データ要求は非常に単純に見えます。文字通り2行で、1行で書くこともできます。







たとえば、15フィールドのPATCHリクエストを作成する方法についての質問に戻りましょう。ここでは、フィールドの名前、そのキー、および値のみを書き込む必要があります。必要なのはこれだけです。ファイルも文字列の作成も、まったく何もありません。便利そうですね。



おそらく、私が仕事で毎日使用している最も重要なAlchemy機能は、クエリの分解と拡張です。







PostgreSQLでインターフェイスを作成しているとすると、アプリケーションは何らかの方法で人を承認し、その人がCRUDを実行できるようにする必要があります。さて、分解することはあまりありません。



データのバージョン管理、さまざまな抽象化を使用する非常に複雑なアプリケーションを作成する場合、生成するクエリは膨大な数のサブクエリで構成される可能性があります。サブクエリはサブクエリと結合されます。さまざまなタスクがあります。また、クエリの分解が非常に役立つ場合があります。これにより、ロジックとコードの設計を大幅に分離できます。



なぜこのように機能するのですか？たとえば、users_table.select（）メソッドを呼び出すと、オブジェクトが返されます。where（）など、結果のオブジェクトに対して他のメソッドを呼び出すと、完全に新しいオブジェクトが返されます。すべてのクエリオブジェクトは不変です。したがって、好きなものの上に構築することができます。

alembicからの移行

これでSQLAlchemyを処理し、ついにAlembicマイグレーションを作成できるようになりました。







Alembicの使用を開始することは、特に前に述べたようにテーブルをすでに説明し、MetaDataオブジェクトを指定している場合は、まったく難しくありません。 alembicをpipinstallし、alembic initalembicと呼びます。 alembic-モジュールの名前。これはコマンドラインです。これがあります。 initはコマンドです。最後の引数は、それを配置するフォルダーです。



このコマンドを呼び出すと、いくつかのファイルが作成されます。これについて詳しく見ていきます。







alembic.iniには一般的な構成があります。 script_locationは、まさにあなたが行きたい場所です。次に、生成する移行の名前のテンプレートと、データベースに接続するための情報があります。







新しい移行用のテンプレートもあります。 「新しい移行が必要です」と言うと、Alembicは特定のテンプレートに従ってそれを作成します。これらすべてをカスタマイズできます。非常に簡単です。このファイルにアクセスして、必要なものを編集します。ここで指定できるすべての変数は、ドキュメントにあります。これは最初の部分です。上部にある種の解説があるので、そこで何が起こっているのかを見るのに便利です。次に、すべての移行に含まれるべき変数のセットがあります-リビジョン、down_revision。今日は彼らと一緒に働きます。さらに-追加のメタ情報。







最も重要な方法は、アップグレードとダウングレードです。 Alembicは、ここでMetaDataオブジェクトがスキーマの説明とデータベースにあるものとの間に見つけた違いを置き換えます。







env.pyは、Alembicで最も興味深いファイルです。コマンド実行の進行状況を制御し、自分でカスタマイズできるようにします。 MetaDataオブジェクトを接続するのはこのファイルです。前に述べたように、MetaDataオブジェクトは、データベース内のすべてのエンティティのレジストリです。



ここでこのMetaDataオブジェクトを接続しています。そしてその時から、Alembicは、ここに私のモデル、ここに私のプレートがあることを理解しています。彼は自分が何を扱っているかを理解しています。次に、Alembicには、オフラインまたはオンラインでAlembicを呼び出すコードがあります。これについても検討します。



これはまさに、プロジェクトでMetaDataを接続する必要がある行です。何かがはっきりしていなくても心配しないでください。私はすべてをプロジェクトに集めてGitHubに投稿しました。あなたはそれを複製して見ることができ、それをすべて感じることができます。







オンラインモードとは何ですか？オンラインモードでは、Alembicはalembic.iniファイルのsqlalchemy.urlパラメーターで指定されたデータベースに接続し、移行の実行を開始します。



なぜこのコードを見ているのですか？ Alembicは非常に柔軟にカスタマイズできます。



さまざまなデータベーススキーマに存在する必要があるアプリケーションがあるとします。たとえば、一度に多数のアプリケーションインスタンスを実行し、それぞれが独自のスキームで動作するようにしたいとします。それは便利で必要な場合があります。



費用は一切かかりません。 context.begin_transaction（）メソッドを呼び出した後、コマンド「SET search_path = SCHEMA」を記述できます。これにより、PostgreSQLに別のデフォルトスキーマを使用するように指示されます。そしてそれがすべてです。今後、アプリケーションは完全に異なるスキームで動作し、移行は別のスキームに移行します。これは1行の質問です。







オフラインモードもあります。ここでは、Alembicはエンジンを使用しないことに注意してください。ここで彼にリンクを渡すだけです。もちろん、エンジンを転送することもできますが、どこにも接続されません。生のクエリを生成するだけで、どこかで実行できます。







つまり、AlembicといくつかのMetaDataとテーブルがあります。そして、最終的に自分で移行を生成したいとします。このコマンドを実行すると、基本的にはそれだけです。 Alembicはデータベースにアクセスし、そこに何があるかを確認します。彼の特別なラベル「alembic_versions」はありますか？これは、移行がこのデータベースですでに展開されていることを示していますか？そこにどのテーブルが存在するかがわかります。データベースに必要なデータが表示されます。これらすべてを分析し、このテンプレートに基づいて新しいファイルを生成すると、移行が行われます。もちろん、Alembicは必ずしも必要なものを生成するとは限らないため、移行で生成されたものを必ず確認する必要があります。しかし、ほとんどの場合、それは機能します。







何を生成しましたか？ユーザーのサインがありました。移行を生成したときに、最初のメッセージを示しました。移行には、以前にalembic.iniで指定された他のテンプレートを使用してinitial.pyという名前が付けられます。



この移行のIDに関する情報もあります。 down_revision = None-これは最初の移行です。



次のスライドは最も重要な部分です：アップグレードとダウングレード。







アップグレードでは、プレートが作成されていることがわかります。ダウングレードでは、この記号は削除されます。 Alembicは、デフォルトで、そのようなコメントを具体的に追加して、そこに移動して編集し、少なくともこれらのコメントを削除します。念のため、移行を確認し、すべてがお客様に適していることを確認しました。これは1つのチームの問題です。すでに移行があります。







その後、この移行を適用する可能性があります。簡単なことではありません。あなたはただ言う必要があります：アレムビックアップグレードヘッド。彼は絶対にすべてを適用します。



頭と言うと、最新の移行に更新しようとします。特定の移行に名前を付けると、それに更新されます。



たとえば、気が変わった場合に備えて、ダウングレードコマンドもあります。これはすべてトランザクションで行われ、非常に簡単に機能します。







つまり、移行があり、それらを実行する方法を知っています。アプリケーションがあり、たとえば、次の質問をしている場合：CIがあり、テストが実行されています。たとえば、移行を自動的に実行するかどうかさえわかりません。たぶんあなたの手でそれをする方が良いですか？



ここにはさまざまな視点があります。おそらく、ルールを守る価値があります。簡単にアクセスできず、データベースを備えた車に乗ることができない場合は、もちろん、自動的に行う方がよいでしょう。



アクセスできる場合は、クラウドで機能するサービスを作成し、いつも持っているラップトップからそこにアクセスできます。そうすれば、自分でそれを実行できるため、より詳細に制御できます。



一般に、これを自動的に行うためのツールはたくさんあります。たとえば、同じKubernetesで。これを実行でき、これらのコマンドを実行できるinitコンテナーがあります。これを行うには、起動コマンドをDockerに直接追加できます。



考慮する必要があるのは、移行を自動的に適用する場合、たとえば、ロールバックしたいができない場合にどうなるかを考える必要があるということです。たとえば、500ギガバイトのデータプレートがありました。あなたは考えました：さて、このデータはもはやビジネスロジックには必要ありません、おそらくそれを落とすことができます。彼らはそれを取り、それを落としました。または、データの損失に伴って変更された列のタイプを変更しました。たとえば、長い列がありましたが、短くなりました。または何かがなくなっています。または、列を削除しました。必要な場合でもロールバックすることはできません。



かつて私はオンプレミス向けの製品を作成しました。これは、マシン上で直接人々のためにexeファイルによってインストールされます。理解したら：はい、あなたは移行を書きました、それは本番環境に入りました、人々はすでにそれをインストールしました。今後5年間で、SLAに従って機能する可能性があり、何かを変更したい場合は、何かが改善される可能性があります。この時点で、不可逆的な変更に対処する方法について考えます。







ここにもロケット科学はありません。アイデアは、これらの列の使用やテーブルの使用をできるだけ避けることができるということです。それらに連絡するのをやめなさい。たとえば、ORMで特別なデコレータを使用してフィールドにマークを付けることができます。彼はログであなたがこのフィールドに触れたくないようだったと言うでしょう、しかしあなたはまだ彼に言及しています。バックログにタスクを作成し、いつか削除するだけです。



どちらかといえば、ロールバックする時間があります。そして、すべてがうまくいけば、バックログの後半でこのタスクを落ち着いて実行します。実際にすべてを削除する別の移行を行います。



ここで最も重要な質問です。移行をテストする理由と方法は？







私が尋ねた人のほとんどはこれをしません。しかし、それを行う方が良いです。これは、痛み、血、汗で書かれたルールです。本番環境で移行を使用することは常に危険です。あなたはそれがどのように終わるかを決して知りません。 CIを構成している場合、完全に正常に動作する本番環境での非常に優れた移行でさえ、ジャークする可能性があります。



実際のところ、移行をテストするときに、たとえば、ステージまたは本番環境の一部をダウンロードすることもできます。プロダクションは大規模になる可能性があり、テストやその他のタスクのために完全にダウンロードすることはできません。開発拠点は、原則として、実際には生産拠点ではありません。彼らは何年にもわたって蓄積できたものの多くを持っていません。







これは、何かを移行したときにデータが破損したり、データの一貫性が失われた古いソフトウェアである可能性があります。誰かが外部キーを追加するのを忘れた場合、それは暗黙の依存関係である可能性もあります。彼はそれがつながっていると思いますが、例えば彼の同僚はそれについて知りません。フィールドも偶然に呼ばれ、接続されているかどうかはまったくわかりません。



それから誰かが入って、ある種のインデックスを直接本番環境に追加することにしました。「今は遅くなりますが、速く動作し始めたらどうなるでしょうか？」誇張しているかもしれませんが、実際にはデータベース内で何かを変更することがあります。



もちろん、スキーマの移行では、ツールにエラーがあります。正直なところ、私はこれに遭遇していません。通常、最初の3つの問題がありました。そして、おそらくデータがどのように転送されるべきかについての仮定におけるより多くのエラー。



非常に大きなオブジェクトモデルがある場合、すべてを念頭に置くことは困難です。常に最新のドキュメントを作成することは困難です。最新のドキュメントはコードであり、ビジネスロジックが完全に記述されているとは限りません。つまり、何をどのように機能させるか、誰が何を念頭に置いているかです。







何を確認できますか？少なくとも移行が始まるという事実。これはすでに素晴らしいです。そして、コードに愚かなタイプミスがないこと。有効なdowngrade（）メソッドがあること、downgrade（）メソッドがSQLAlchemyによって作成されたすべてのデータタイプを削除することを確認できます。



SQLAlchemyは多くの素晴らしいことをします。たとえば、テーブルを記述してEnum列タイプを指定すると、SQLAlchemyはPostgreSQLでその列挙型のデータタイプを自動的に作成します。ただし、downgrade（）メソッドでこのデータタイプを削除するコードは自動的に生成されません。



これを覚えて確認する必要があります。移行をロールバックして再適用する場合、upgrade（）メソッドで既存のデータタイプを作成しようとすると、例外がスローされます。そして最も重要なことは、移行によってデータが変更された場合、アップグレード時にデータが正しく変更されることを確認する必要があります。また、ダウングレード時に副作用なしに正しくロールバックすることを確認することが非常に重要です。







テスト自体に進む前に、テストを作成するための最善の準備方法を見てみましょう。私はこれに対する多くのアプローチを見てきました。一部の人々は、ベース、プレートを作成し、それをすべてクリーンアップするフィクスチャを作成し、ある種の自動適用フィクスチャを使用します。しかし、100％保護し、完全に隔離されたスペースでテストを実行する理想的な方法は、別のデータベースを作成することです。



データベースを作成および削除できる素晴らしいsqlalchemy_utilsモジュールがあります。 PostgreSQLでは、彼は次のことも確認します。クライアントの1つがスリープ状態になり、切断しなかった場合、「誰かがデータベースを使用しています。データベースを使用して何もできません。削除できません」というエラーでクラッシュすることはありません。代わりに、彼は誰がそれらに接続したかを冷静に確認し、これらのクライアントを切断し、冷静にベースを削除します。



データベースを構築し、各テストに移行を適用することは、必ずしも迅速なプロセスではありません。これは次のように解決できます。PostgreSQLはテンプレートからの新しいデータベースの作成をサポートしているため、データベースの準備を2つのフィクスチャに分割できます。



最初のフィクスチャは1回実行され、すべてのテスト（scope = session）が実行され、データベースが作成され、それに移行が適用されます。 2番目のフィクスチャ（scope = function）は、最初のフィクスチャのベースに基づいて、各テストのベースを直接作成します。



テンプレートからデータベースを作成するのは非常に高速で、各テストに移行を適用する時間を節約できます。







一時的にデータベースを作成する方法について話しているだけなら、そのようなフィクスチャを書くことができます。何が起きてる？ランダムな名前を生成します。念のため、pytestの最後に追加します。これにより、Posticoを介してlocalhostに移動したときに、テストによって作成されたものと作成されなかったものを理解できます。



次に、その人が示したデータベースへの接続に関する情報を含むリンクから、新しいデータベースを持つ新しいリンクを生成します。作成してテストに送信します。人がこのデータベースを操作した後、それを削除します。







このデータベースに接続するためにエンジンを準備することもできます。つまり、このフィクスチャでは、依存関係として使用されていた以前のフィクスチャを参照します。エンジンを作成してテストに送信します。







では、どのようなテストを書くことができますか？最初のテストは、私の同僚の素晴らしい発明です。登場してから、移行の問題を忘れてしまったようです。



これは非常に簡単なテストです。プロジェクトに一度追加します。それはGitHubのプロジェクトにあります..。あなたはそれをあなたにドラッグして、おそらく問題の約80パーセントを追加して忘れることができます。



それは非常に単純なことをします：それはすべての移行のリストを取得し、それらに対して反復を開始します。アップグレード、ダウングレード、アップグレードを呼び出します。







たとえば、5つの移行があります。これがどのように機能するか見てみましょう。これが最初の移行です。私たちはそれを実現しました。最初の移行をロールバックし、再度実行します。ここで何が起こったのですか？実際、ここでは、たとえば2回はテーブルを作成できなかったため、ダウングレード（）メソッドを正しく実装していることがわかりました。



ある人がいくつかのデータタイプを作成した場合、タイプミスがなく、一般的には少なくとも何らかの形で機能するため、それらも削除したことがわかります。



その後、テストが進みます。彼は2回目の移行を行い、すぐに実行し、1ステップロールバックし、再び前進します。そして、これは移行の回数だけ発生します。



このテストの目的は、データ構造を変更する際の基本的なエラー、問題を見つけることです。



階段は空のベースから始まり、通常は非常に高速です。つまり、このテストはデータ構造に関するものです。これは、移行時にデータを変更することではありません。しかし、全体として、それはあなたの命を非常によく救うことができます。



迅速な修正が必要な場合は、これがそれです。このルールはです。原則として、プロジェクトに挿入すると、簡単になります。







このテストは次のようになります。すべてのリビジョンを取得し、Alembic構成を生成します。これが前に見たもの、alembic.iniファイルです。これがget_alembic_config関数です。ベースへのパスを指定したため、このファイルを読み取り、一時ベースを追加します。その後、Alembicコマンドを使用できます。



以前に実行されたコマンド（alembic upgrade head）も安全にインポートできます。残念ながら、このスライドはすべてのインポートに適合するわけではありませんが、私の言葉を信じてください。これは、alembic.comのインポートアップグレードからのものです。そこで設定を翻訳し、どこでアップグレードを行うかを指示します。次に、「ダウングレード」と言います。



ダウングレードでは、移行はdown_revision、つまり前のリビジョン、または「-1」にロールバックされます。



「-1」は、現在の移行をロールバックするようにAlembicに指示する別の方法です。最初の移行が開始されたときに非常に関連性があり、そのdown_revisionはNoneですが、AlembicAPIではdowngradeコマンドにNoneを渡すことはできません。



その後、upgradeコマンドが再度実行されます。



次に、データを使用して移行をテストする方法について説明します。







データの移行は、通常は非常に単純に見えるようなものですが、最も痛いものです。あるテーブルからデータを選択、挿入、取得し、それをわずかに異なる形式で別のテーブルに転送するように見えるでしょう-もっと簡単なことは何でしょうか？



このテストについては、前のテストとは異なり、開発に非常に費用がかかると言われています。大規模な移行を行ったとき、すべての不変条件を確認するのに6時間かかることがありましたが、すべてを説明しても問題ありません。しかし、私がすでにこれらの移行を行っていたとき、私は落ち着いていました。







このテストはどのように機能しますか？アイデアは、現在テストしたいものまでのすべての移行を適用することです。変更されるデータのセットをデータベースに挿入します。暗黙的に変更される可能性のある追加のデータを挿入することを考えることができます。次に、アップグレードします。データが正しく変更されたことを確認し、ダウングレードを実行して、データが正しく変更されたことを確認します。







コードは次のようになります。つまり、リビジョンによるパラメータ化もあり、パラメータのセットがあります。ここでエンジンを受け入れ、テストを開始する移行を受け入れます。



次に、テストしたいrev_headです。そして、3つのコールバック。これらは、どこかで定義したコールバックであり、何かが行われた後に呼び出されます。そこで何が起こっているのかを確認できます。

例はどこにありますか？

私はそれをすべてGitHubの例に詰め込みました。そこには実際には多くのコードはありませんが、スライドに追加するのは非常に困難です。私は最も基本的なことに耐えようとしました。 GitHubにアクセスして、プロジェクト自体でどのように機能するかを確認できます。これが最も簡単な方法です。



他に注意を払う価値があるものは何ですか？起動時に、Alembicは起動されたフォルダーでalembic.ini構成ファイルを探します。もちろん、環境変数ALEMBIC_CONFIGを使用してパスを指定できますが、これは必ずしも便利でわかりやすいとは限りません。



別の問題：データベースに接続するための情報はalembic.iniで指定されていますが、多くの場合、複数のデータベースを順番に操作する機能が必要です。たとえば、移行をステージに展開してから、本番環境に展開します。一般に、SQLALCHEMY_URL環境変数で接続情報を指定できますが、これはソフトウェアのエンドユーザーにはあまり明白ではありません。



また、エンドユーザーが「alembic」よりも「$ project $ -db」ユーティリティを使用する方がはるかに直感的です。



プロジェクトの例を見るときは、staff-dbユーティリティを見てください。これはAlembicの薄いラッパーであり、Alembicをカスタマイズするもう1つの方法です。デフォルトでは、プロジェクト内のalembic.iniファイルをその場所に関連して検索します。ユーザーが彼女と呼んでいるフォルダーから、彼女自身が構成ファイルを見つけます。また、staff-dbは引数--db-urlを追加します。これを使用して、データベースに接続するための情報を指定できます。そして、重要なことに、一般的に受け入れられている--helpオプションを渡してそれを確認してください。結局のところ、ユーティリティの名前は直感的です。



すべての実行可能なプロジェクトコマンドは、「staff」モジュールの名前で始まります。RESTAPIを実行するstaff-apiと、基本状態を管理するstaff-dbです。このパターンを理解すると、クライアントはプログラムの名前を書き込み、フルネームを忘れた場合でも、TABキーを押すことで利用可能なすべてのユーティリティを表示できるようになります。私はすべてを持っています、ありがとう。