Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Meta-issue: Deployment

オープン
  • 何か問題がありますか？
#359 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
20/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
静か
技術スタック
sql
領域
backend, cloud, security

調査の方向性

実装ファイルやテストは特定されていません。まず、Positron と Workbench から Connect へのデプロイに関する検討事項を確認してください。これには、Quarto レポート、Shiny アプリケーション、バージョニング、バックエンド接続モード、認証情報モードが含まれます。プロジェクトで合意済みのデプロイ設計と、スコープが定義された実装計画が策定されれば完了です。

索引モデルが issue の本文から書いたものです。

説明

integration

This issue exist to track discussions around deployment. For the initial phase we will focus on Connect deployment from Positron and Workbench as this is the stack we control - others may think about deployment in other context if they wish to do so in the mean time.

Key questions:

What does ggsql deployment look like?

Right now deployment would be in the form of a quarto report or some sort. However, the R bindings also support deploying shiny applications with ggsql code inside.

I do envision a mode where you deploy a single .ggsql file and you get an embeddable visualisation. Depending on how ggsql's own multiplot support evolves this may end up being a viable dashboard solution, though I'm not sure SQL provides the best syntax for layout work. If not, do we need a new format for dashboard-y deployments or does quarto serve that need?

For deployment, we also need to think about ggsql versioning. We are in a blissful state of just having to declare a single version and not black pit of 100s of dependencies, but declare it we must somehow. Is this a Connect responsibility or should ggsql itself do something about this?

What kind of backend connection is kept - with what kind of credentials?

Our happy path is that an analyst sits on their computer, developing an analysis using ggsql either in Positron or Workbench. They have their credentials set up so they can connect to e.g. Snowflake and visualise that data directly. They arrive at an end product and hit deploy. The deployment target is send to Connect, along with the credentials and everything just magically works. We must strive for this to be the case!

However, I can see multiple modes of connection with a backend depending on the needs, and also multiple modes of credentials:

Connection modes:

  • Keep a connection to the original backend, updates to the database is reflected in the visualisation whenever it is presented
  • Cache the main data sources in a local DuckDB instance and query against that in the backend - this may be updated periodically but not real-time
  • Embed the data in a "static" deployment (i.e. connection is severed)

Credential mode:

  • Use the authors credentials/credentials provided specifically for this deployment. All visits will use the same credentials and it is up to the analyst to not expose confidential information in the visualization
  • Visitor brings their own credentials and these are used when querying the database and creating the plot. The visitor only sees data for which they have been granted access. This mode explicitly requires the first connection mode described above
主要言語
Rust
スター
565
フォーク
31
平均マージ
2日 12時間
マージ済み PR（30日）
16

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

posit-dev/ggsql のほかの issue

posit-dev/ggsql の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。