mirror of
https://github.com/microsoft/dbt-fabricspark.git
synced 2026-11-04 12:02:24 +00:00
RakiandCopilot
dc748f8273
* Copilot instructions * feat: cross-workspace 4-part naming (read-only) Add support for `workspace_name` on a model's `config()` so a single dbt project can read data across Fabric workspace boundaries. The relation renders as `` `workspace`.`lakehouse`.`schema`.identifier `` and Fabric Livy federates the SELECT to the named workspace. * `FabricSparkRelation.workspace` carries the workspace through `create_from`; `render()` only emits the prefix when the database segment is included so temp views/CTEs stay session-scoped. * `workspace_name` is registered on `FabricSparkConfig`; a parse-time validator (`adapter.validate_workspace_name_supported`, hooked from `fabricspark__generate_database_name`) rejects the config when the write target is a non-schema-enabled lakehouse — Fabric Livy only honours 4-part names against schema-enabled lakehouses. * `_build_spark_relation_list`, `list_relations_without_caching`, and `_get_columns_for_catalog` propagate the workspace prefix. * CI is now wired against two real Fabric workspaces. The orchestrator provisions a schema-enabled lakehouse in WS2, seeds a fixture, runs cross-workspace functional tests, and nukes both workspaces. Required env vars: `WORKSPACE_ID_1`, `WORKSPACE_NAME_1`, `WORKSPACE_ID_2`, `WORKSPACE_NAME_2`. Missing vars fail the orchestrator immediately. * Cross-workspace **writes** are not supported by Fabric Livy (`Artifact not found` on 4-part DDL targets); the README and tests reflect this and only exercise the read path. Closes #162, #165. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Changelog shouldn't be updated until the release --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
5 lines
72 B
Bash
5 lines
72 B
Bash
WORKSPACE_ID_1=
|
|
WORKSPACE_NAME_1=
|
|
WORKSPACE_ID_2=
|
|
WORKSPACE_NAME_2=
|