Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Run the warehouse implementations against real Snowflake and Databricks

Đang mở
  • Có gì không ổn?
#303 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
python, r, sql, sqlalchemy, terraform
Lĩnh vực
ci-cd, databases, infrastructure, testing

Hướng nghiên cứu

Bắt đầu bằng cách đọc pkg-r/tests/testthat/test-live-warehouses.R, helper-live-warehouses.R và pkg-r/tests/testthat/README.md để hiểu các tùy chọn và skip hiện có cho các live test. Xem lại các case dùng chung catalog-access-errors.json và definition-warehouse-sql.json trước khi xác định warehouses và thông tin xác thực nên được lấy từ đâu. Được xem là hoàn tất khi đã quyết định mô hình thực thi và có kế hoạch triển khai bao quát việc provisioning, các harness Python và R, xử lý thông tin xác thực, các skip phù hợp và các live assertion.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

py r tests

Everything commons knows about Snowflake and Databricks has been verified against a fake. Nothing in pkg-py has ever run a statement against a real warehouse, and the R live tests have no way to run anywhere except one person's laptop. The catalog readers, the access and session checks, and the warehouse SQL emitters are all specified against what we believe those systems return.

What exists today

pkg-r/tests/testthat/test-live-warehouses.R (744 lines) plus helper-live-warehouses.R connect through ODBC (odbc::snowflake(), a DSN named Databricks) and skip unless R options name real objects: a test table, a denied table, an alternate Snowflake role, semantic views, parameterized models. pkg-r/tests/testthat/README.md documents the options. Nothing provisions the objects those options point at, no CI job runs any of it, and pkg-py has no equivalent at all: every warehouse test there drives a fake backend that replays canned rows.

The open question

Where does the warehouse come from? This is the decision the rest depends on, so it should be made first. Options worth pricing:

  • a shared Posit-owned Snowflake account and Databricks workspace, with credentials in GitHub secrets;
  • per-developer trial accounts plus a provisioning script;
  • Databricks free edition or a Snowflake trial, created and torn down in CI;
  • accepting that this stays manual, and lives in a documented pre-release checklist rather than in CI.

Then the mechanics

  • Provisioning as code. The fixtures are not just a table. The access tests need an object the test principal genuinely cannot read, and the session test needs a second usable role. A SQL script (or Terraform) that creates the schema, tables, views, roles, and grants would bring any account to a known state and stop the test options being hand-typed identifiers.
  • A Python harness of the same shape. Python connects through SQLAlchemy rather than ODBC/DBI, so this needs snowflake-sqlalchemy and databricks-sqlalchemy as optional dev dependencies, an environment-variable or config equivalent of the R options, and a clean skip when they are unset.
  • Credential handling. What reaches CI, what stays local, and what a contributor without warehouse access sees. Today they get a clean skip, which should stay true.
  • Scope of what gets asserted. Prefer what a fake cannot tell us over restating unit tests: identifier case folding per backend, the real row shapes of SHOW OBJECTS, DESC TABLE, system.information_schema and DESCRIBE TABLE, the SQLSTATE and message a genuine permission refusal carries, the session identity queries, and whether the Snowflake and Databricks SQL the definition emitters produce actually executes.

Why it matters

tests/shared/catalog-access-errors.json decides whether a driver failure is an authorization refusal, a transient fault, or neither, and commons caches the refusal or retries based on that answer. Its cases were written from documentation rather than from a captured failure. tests/shared/definition-warehouse-sql.json pins SQL that no warehouse has ever parsed, and it is hand-maintained precisely because there is no upstream authority to check it against. A live run is what turns both from plausible into verified. The same applies to the native semantic-model probes for Snowflake semantic views and Databricks metric views, which cannot be written honestly without one.

Not urgent for the conference demo, which runs on DuckDB, and not a blocker for the data layer milestone. It is what stands between "the warehouse support is implemented" and "the warehouse support is known to work".

Ngôn ngữ chính
Python
Star
58
Fork
2
Merge trung bình
2 ngày 5 giờ
Pull request đã merge (30 ngày)
50

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của posit-dev/commons

Tất cả issue của posit-dev/commons

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.