ワークスペース¶

ファイルの管理¶

ワークスペース、ファイル、フォルダの名前の変更、削除、移動、整理ができます。

ワークスペース、ファイル、またはフォルダの名前を変更または削除します。

1. ターゲットにカーソルを合わせ、縦の省略記号 （その他のアクション）を選択します。

2. Rename または Delete を選択します。削除を選択すると、確認のプロンプトが表示されます。

• ワークスペースにフォルダを作成するには、ワークスペースまたは既存のフォルダの横にある + を選択します。

• ファイルやフォルダを整理するには、任意のファイルやフォルダを同じワークスペースの別の場所にドラッグします。ワークシートをワークスペースにドラッグすることもできます。

複数のファイルや結果を1つのレイアウトで表示¶

タブと分割ペインで複数のファイルを管理すると、いくつかの利点があります。

• コードや結果を並べて比較ワークシートのクエリを参照しながら、別のクエリを実行できます。

• マルチタスクをより効率的に: 異なるセル、出力、ファイルを一度に表示でき、切り替えの手間が省けます。

ワークスペースのレイアウトを調整するには、 Workspaces ペインで縦の省略記号 （その他のアクション）を選択し、適切なオプションを選択します：

1. 右に分割

2. 下に分割

3. その他を閉じる

Gitワークスペースの作成¶

Git リポジトリに接続したワークスペースを作成し、 Snowsight で直接ファイルを開発・管理することができます。

新しいGit同期ワークスペースを作成するには

1. Snowsight にサインインします。

2. ナビゲーションメニューで Projects » Workspaces を選択します。

3. Workspaces メニューで、 From Git repository を選択します。

4. Git リポジトリから URL をコピーし（たとえば https://www.github.com/my-user/my-repo-name）、 Repository URL フィールドに貼り付けます。

5. オプション: 新しいGit同期ワークスペースの名前を変更します。

6. API Integration メニューで、 API 統合.を選択します。

   API 統合はアカウント管理者によって作成されます。ステップ4で使用しているGitリポジトリ URL へのアクセスを許可する必要があります。詳細については、 Gitを使用するためのSnowflakeの設定 をご参照ください。

   また、Gitプロバイダーとして GitHub を使用して認証として OAuth を好む場合、アカウント管理者は、 OAuth をサポートする API 統合コードを作成する必要があります。例:

   CREATE OR REPLACE API INTEGRATION api_integration_name
      API_PROVIDER = git_https_api
      API_ALLOWED_PREFIXES = ('https://github.com/')
      API_USER_AUTHENTICATION = (
         TYPE = snowflake_github_app
      )
      ENABLED = TRUE;
   

   Copy

7. API 統合の基になる、認証を選択します。

   • OAuth2 - Sign in を選択して、 GitHub リポジトリで認証します。サインイン後は、次回以降のセッションで認証情報を入力する必要はありません。なお、 OAuth2 は PrivateLink 環境では可用性はありません。

   • Personal access token - トークンを含むオブジェクトが格納されているデータベースとスキーマを選択します。新しい秘密を作成するには、 + Secret を選択し、必要な詳細を入力します。このシークレットまたはすべてのシークレットへのアクセスを許可するように API 統合を構成する必要があります。

   • Public repository - 認証を必要としない公開リポジトリを使用している場合は、このオプションを選択します。ワークスペースの変更をコミットして、この公開リポジトリにプッシュすることはできません。

8. Create を選択します。

ブランチの著者情報および認証情報の更新¶

デフォルトでは、Git リポジトリへの変更のコミットには Snowflake のメールアドレスとユーザー名が使用されます。いつでも更新できます。

1. Snowsight にサインインします。

2. ナビゲーションメニューで Projects » Workspaces を選択します。

3. Changes タブを選択します。

4. 省略記号を選択し、 Edit credentials を選択します。

5. 作成者名とメールを指定してください。

6. Update を選択します。

新しいブランチの作成¶

現在のブランチから新しいブランチを作成して、単独で変更作業を行うことができます。

1. Snowsight にサインインします。

2. ナビゲーションメニューで Projects » Workspaces を選択します。

3. Changes タブを選択します。

4. リポジトリのドロップダウンを選択します。

5. + New を選択します。

6. 新しいブランチ名を指定し、 Create を選択します。

別の支店に変更¶

保存はしたもののコミットしていない変更がある場合、ブランチを切り替える前にその変更をどのように扱うかを選択する必要があります。

1. Snowsight にサインインします。

2. ナビゲーションメニューで Projects » Workspaces を選択します。

3. Git ワークスペース表示で、 Changes を選択します。

4. ブランチメニューから、切り替えたいブランチを選択します。

   ヒント：リストをフィルターするには、ブランチ名をタイプしてください。

リモートブランチの取得¶

新しいブランチが Snowsight の外部 (たとえば Git プロバイダーで作成したものなど) で作成された場合は、 Fetch All オプションを使用して Git と同期したワークスペースに取り込むことができます。これで利用可能なリモートブランチのリストが更新されます。

1. Snowsight にサインインします。

2. ナビゲーションメニューで Projects » Workspaces を選択します。

3. Git ワークスペース表示で、 Changes を選択します。

4. Pull メニューの横にある下向き矢印を選択し、 Fetch All を選択します。取得が終了すると、新しく作成されたリモートブランチがブランチリストに表示され、チェックアウトが可能になります。

更新されたファイルの表示¶

最後にコミットしてプッシュしてから追加、削除、変更されたすべてのファイルを表示します。

1. Snowsight にサインインします。

2. ナビゲーションメニューで Projects » Workspaces を選択します。

3. フォルダ表示の上部で、 Changes を選択します。変更されたファイルは M で示され、追加されたファイルは A で示され、削除されたファイルは D で示されます。

4. エディタで変更点の差分を視覚的に表示するには、ファイルを選択します。

更新のコミットとプッシュ¶

変更内容を確認したら、ワークスペース内からコミットしてリモートの Git リポジトリにプッシュします。

更新したファイルをコミットしてリモートの Git リポジトリにプッシュします。

1. Snowsight にサインインします。

2. ナビゲーションメニューで Projects » Workspaces を選択します。

3. フォルダ表示の上部にある Changes を選択します。

4. Commit message フィールドにコミットメッセージを書いてください。

5. Push を選択します。

6. コミットメッセージを書き、 Push を選択して Git リポジトリに更新をプッシュします。

   注釈

   コンフリクトが検出された場合、最初にプルするよう促されます。コンフリクトのあるファイルのリストを確認するには、 Pull を選択します。

コンフリクトの表示と解決¶

プッシュ中にコンフリクトが発生した場合、再度コミットする前にワークスペースで直接表示し、解決することができます。

1. ワークスペースで、フォルダ表示の上部にある Changes を選択します。1つまたは複数のファイルが競合している場合、メッセージが表示の上部に表示されます。競合のあるファイルは、赤い M で示されます。

2. エディターでコンフリクトの差分を表示するには、ファイルを選択します。File with conflicts では、相違点はインラインで強調表示されます。

3. 現在の変更、入力された変更、または両方の変更を受け入れます。マージ結果が表示されます。

4. Diff View の下に、現在のバージョンとリモートバージョンを並べて表示することができます。

5. Accept all current または Accept all remote を選択します。

6. 競合を解決したら、 Push を選択します。

7. コミットメッセージを書いてください。

8. Push を選択します。

デフォルトのエディターを設定または元に戻す¶

すべてのユーザーに対して、アカウント全体のデフォルトエディターをワークスペースに設定する場合

ALTER ACCOUNT SET USE_WORKSPACES_FOR_SQL = 'always';

この設定を戻して以前のデフォルトエディターを使用するが、ワークスペースをデフォルトにするSnowflake管理 BCR を尊重する場合

ALTER ACCOUNT UNSET USE_WORKSPACES_FOR_SQL;

以前のエディターに戻り、ワークスペースをデフォルトにするSnowflake管理 BCR を一時的に無視する場合

ALTER ACCOUNT SET USE_WORKSPACES_FOR_SQL = 'never';

ワークスペースを無効化¶

ワークスペースを無効にするには、 ENABLE_PERSONAL_DATABASE アカウントレベルパラメーターを FALSE にセットします：

ALTER ACCOUNT SET ENABLE_PERSONAL_DATABASE = FALSE;

このパラメーターには ACCOUNTADMIN 権限が必要です。FALSE にセットすると、ワークスペースは機能しなくなりますが、ワークスペースは Snowsight ナビゲーションメニューにリストされます。

Workspacesでセカンダリロールを有効にする必要はありませんが、セッションポリシーでセカンダリロールを明示的にブロックしている場合は、セッションポリシーが削除されるまで、現在の制限によってWorkspacesが機能しなくなります。

ドロップされたユーザーから ワークスペースを復元する¶

ユーザーがドロップされた場合でも、個人データベース（PDB）、およびそれらのワークスペース内のすべてのファイルは保持されます。その PDB はその後、:code:`DROPPED_USER$<dropped_user_name>_<timestamp>`に名前が変更されます。

ドロップされたユーザーの PDBからワークスペースを復元するには、次のステップに従います。

1. 削除されたユーザーの PDBを見つけます。SHOW DATABASES コマンドと LIKE 関数を使用して、特定のデータベースを見つけます。

   SHOW DATABASES LIKE 'dropped_user%';
   

   Copy

2. PDBでワークスペースを表示します。利用可能なワークスペースを一覧表示するには、SHOWWORKSPACESINDATABASE コマンドを使用します。

   SHOW WORKSPACES IN DATABASE DROPPED_USER$dropped_user_1754344912;
   

   Copy

3. 回復したものから新しいワークスペースを作成します。CREATEWORKSPACE ... FROM コマンドを使用して、回復したワークスペースから新しいワークスペースを作成します。

   これにより、コンテンツが新しい場所にコピーされ、アクセスできるようになります。

   注釈

   USER$ 修飾子を使用して、ワークスペースを自分の個人データベースに配置する必要があります。それ以外の場合はエラーが発生します。データベース名の末尾のタイムスタンプはさまざまです。

   FROM 'snow://workspace/DROPPED_USER$dropped_user_1754344912.PUBLIC."to_be_recovered"/versions/head';
   

   Copy