spellbook
v2-2-0 Add CryptoPunks, Labels
スペルブックへようこそ。魔法の呪文を唱えてブロックチェーンを制御します。
Spellbook は、コミュニティのために、コミュニティによって構築された Dune の解釈レイヤーです。
Spellbook は dbt プロジェクトです。各モデルは、小規模な構文糖衣 (依存関係を取得し、結果のテーブルの構築を支援することを目的) を備えた単純な SQL クエリであり、生のレコードとデコードされたレコードを解釈可能なブロックチェーン データに変換するタスクのごく一部を実行します。
Spellbook はコミュニティのために、コミュニティによって構築されています。PR を送信したり、小さな変更を提案したりバグを追跡したりするための課題を作成したり、このプロジェクトの将来を導くためのディスカッションに参加したりすることで、見つけたギャップを埋めることができます。
Spellbook には、Dune のデータ解釈層に貢献するための多くの可動部分と特定の設計原則があります。コントリビューターが最も効率的に参加できるように準備するために、docs ディレクトリには、一般的な質問に答え、リポジトリが現状の設定になっている理由に関する情報を提供する幅広いトピックが含まれています。 Spellbook で開発し、疑問が生じた場合は、このセクションを読んで参照してください。また、Dune チームはこれらのドキュメントにリンクして頻繁に質問に答え、意識を高め、コミュニケーションをクリーンに保ちます。
Spellbook を拡張するために、リポジトリは複雑な DBT 系統を少し解消し、重点領域をクリーンに保つためのサブプロジェクトを導入しました。これは、下流のオーケストレーションが本番環境でスペルを最新の状態に保つのにも役立ちます。 Spellbook の DBT サブプロジェクトは、1 つのリポジトリ内の複数の DBT プロジェクトにすぎません。現在のプロジェクトの構造:
dbt_subprojectsdaily_spellbookhourly_spellbookdexdexまたはdex_aggregatorスキーマ内に存在するすべての呪文nftnftスキーマ内に存在するすべての呪文solanatokensサブプロジェクトの詳細については、このディスカッションにアクセスし、そこで質問してください。
すぐに仕事に取り掛かりたいですか？ここのガイドに従って開始してください。
Dune のエンジンに対して呪文をテストするために、複雑なローカル設定は必要ありません。 PR を送信すると、CI パイプラインが実行されてテストされ、ジョブが正常に終了すると、PR が作成したデータを dune.com から直接クエリできるようになります。
ライブ テーブルの場合と同じようにクエリを作成し、テスト スキーマを使用して PR が作成したテーブルをフェッチするだけです。
test_schema.git_dunesql_{{commit_hash}}_{{table_name}}
正確な名前は、 dbt run initial model(s)でdbt slim ciアクションのログを確認することで簡単に見つけることができます。
注意: CI パイプラインに構築されたテスト テーブルは、最大 24 時間存在します。テーブルが存在しない場合は、パイプラインの再実行をトリガーし、テスト テーブルを再作成します。
私たちはコミュニティとつながるために Discord を使用しています。質問がある場合、または特定の PR に関するサポートを求める場合は、Dune の Discord の Spellbook チャンネルにアクセスしてください。実践しながら学び、活気に満ちたコミュニティを活用して前進することをお勧めします。
git config --global core.autocrlf trueを設定してください。もっと詳しく少し下にスクロールすると、これのビデオバージョンを見ることができます。
CLI (コマンド ライン インターフェイス) 内で Spellbook リポジトリに移動します。
cd userdirectorygithubspellbook
# Change this to wherever spellbook is stored locally on your machine.Spellbook リポジトリにある pipfile を使用して、以下の install コマンドを実行して Pipenv を作成します。
pipenv installインストールが失敗する場合、考えられる理由の 1 つは、スクリプトが静的な Python バージョンを探しており、間違った Python バージョンによるエラーが発生する可能性が非常に高いことです。このエラーが発生した場合は、次のようにして Python のバージョンを確認してください。
python --version次に、任意のテキスト エディタ プログラムを使用して、Spellbook ディレクトリ内の pipfile 内の Python バージョンを自分の Python バージョンに変更します。少なくとも Python 3.9 が必要です。 pipfile の Python バージョンを変更した場合は、 pipenv install再度実行します。
これで、このプロジェクトの仮想環境をアクティブ化する準備ができました。次のコマンドを実行して環境に入ります。
pipenv shellこれで、このプロジェクト用の仮想環境が作成されました。仮想環境の詳細については、こちらをご覧ください。
Spellbook リポジトリ内には、ルート ディレクトリに複数の dbt プロジェクトがあります。ユースケースに応じて、適切なプロジェクトに移動します。
cd ../spellbook/dbt_subprojects/<subproject_name>/各サブプロジェクトには、さまざまな構成を含む独自の dbt プロジェクト ファイルがあります。 CLI が正しいプロジェクト ディレクトリに移動したら、次の手順に従います。
dbt プロジェクトをクリーンアップするには
dbt cleandbt プロジェクトの依存関係をプルするには、次のコマンドを実行します。
dbt depsモデルを生の SQL にコンパイルし、dune アプリで実行して検証するには、次の手順を実行します。
dbt compile各 Spellbook サブプロジェクトには、dbt にコマンドの実行方法を指示するのに役立つprofiles.ymlファイルが含まれています。プロファイルは、ここなどの各サブプロジェクト ディレクトリにあります。 Dune チームが意図的に変更しない限り、これを変更する必要はありません。
profiles.ymlファイルは各サブプロジェクトのルート ディレクトリに保存されているため、期待どおりにdbt compile実行するには、ユーザーがコマンド ラインでサブプロジェクトごとのルート ディレクトリに存在する必要があるのはこのためです。
dbt コンパイルは、JINJA および SQL のテンプレート化された SQL を、Dune UI で実行できるプレーンな SQL にコンパイルします。 Spellbook ディレクトリには、Dune のすべてのモデルのプレーン SQL バージョンを含むtargetという名前のフォルダーが作成されました。これらのアクションをすべて完了する前にリポジトリに変更を加えた場合は、少なくともコンパイル プロセスが正しく動作することを確認できます。大きなエラーがある場合、コンパイル プロセスは完了しません。事前にディレクトリに変更を加えていない場合は、ここでリポジトリ内でファイルの追加、編集、または削除を開始できます。その後、ディレクトリでの作業が完了したら、 dbt compile再度実行し、dune.com で単純な言語の SQL クエリをテストします。
マシン上でこのインストールを一度実行したことがある場合、dbt に戻るには、単に Spellbook リポジトリに移動し、 pipenv shell実行するだけで、 dbt compile再度実行できます。
dbt モデル ステートメントとテスト ステートメントを単純な SQL にコンパイルできるようになりました。これにより、通常の dune.com 環境でこれらのクエリをテストできるため、呪文を開発する際のエクスペリエンスが向上するはずです。クエリを実行すると、タイプミス、論理エラー、不一致に関するフィードバックがすぐに得られます。これにより、これらの呪文をより迅速に展開し、潜在的な間違いを回避することができます。
dbt で呪文を作成する際に考慮すべき新しい概念がいくつかあります。ウィザードが遭遇する最も一般的なものは、参照、ソース、鮮度、テストです。
各クエリの本文では、テーブルは refs（例{{ ref('1inch_ethereum') }}またはソース、ex {{ source('ethereum', 'traces') }}のいずれかとして参照されます。 Ref は他の dbt モデルを参照し、モデル自体がエイリアス化されている場合でも、 1inch_ethereum.sqlのようなファイル名を参照する必要があります。ソースとは、dbt によって生成されない「生の」データまたはテーブル/ビューを指します。 ref とsource を使用すると、依存関係ツリーを自動的に構築できます。
ソースとモデルは、テストやその他の属性が定義される schema.yml ファイルで定義されます。
ベスト プラクティスは、新しいモデルごとに一意のテストと非 null テストを主キーに追加することです。同様に、すべての新しいソースに鮮度チェックを追加する必要があります (ただし、ソースが他の場所で使用されている場合は鮮度を再テストしないようにします)。
テーブルと列に説明を追加すると、テーブルを見つけて使用するのが容易になります。
models :
- name : 1inch_ethereum
description : " Trades on 1inch, a DEX aggregator "
columns :
- name : tx_hash
description : " Table primary key: a transaction hash (tx_hash) is a unique identifier for a transaction. "
data_tests :
- unique
- not_null
sources :
- name : ethereum
freshness :
warn_after : { count: 12, period: hour }
error_after : { count: 24, period: hour }
tables :
- name : traces以下の dbt に関するその他のドキュメントへのリンクを参照してください。
ドキュメントを生成し、Web サイトとして表示するには、次のコマンドを実行します。
dbt docs generatedbt docs serve dbt initを使用して dbt を設定しておく必要がありますが、これらのコマンドを実行するためにデータベース資格情報は必要ありません。ドキュメントに貢献する方法の詳細については、dbt docs ドキュメントを参照してください。
プレビューとして、次のようなことができます。
