Forum Discussion
Branched workspaces: Creating Views in the Datawarehouse that reference a Lakehouse table
Hi v-lgarikapat,
Thank you for your response and help. Since my initial post, we've tried a few scenarios and decided to house data stored in their own workspace (workspace dev 1), and have operational activities, like data pipelines and notebooks in another workspace (workspace dev 2). Still adopting the use of environments, but each environment will have two workspaces associated with it. Then, when devs pull code from workspace dev 1 only, they are only pulling operational artifacts. Using shortcuts proved confusing for Fabric when branching and pushing code to the develop branch, due to Lakehouses not being supported by git currently. We also didn't like the fact that the data in tables get deleted each time a table change is merged from a feature branch into develop.
Using this approach, we can:
* Create views and stored procedures in the data warehouse on data in the lakehouses, without having to use shortcuts.
* eliminated the issues we were encountering when branching code from the develop branch/ workspace into another branched workspace.
* still use version control and the PR process in git on the operational activity code.
* version control the data warehouse and SQL server db, by having it on another branch.
Hi caseybks ,
Thanks for reaching out to the Microsoft fabric community forum.
Thanks for your prompt response
Create a dedicated Reference Lakehouse workspace that holds all shared Lakehouse tables, and then have each developer create shortcuts to it in their own branched workspace without committing those shortcuts to Git. This keeps the Lakehouse centralized and avoids duplication, especially when naming shortcuts consistently (using a ref_ prefix). For views or stored procedures, instead of hardcoding Lakehouse paths, you can parameterize them using SQL variables or dynamic references, which adds flexibility across branches. If views become too brittle, another option is to use Data Pipelines to materialize Lakehouse tables into the Warehouse, creating stable, Git-tracked tables that views can safely reference. And finally, managing the Warehouse separately as a SQL DB project outside Fabric’s Git sync lets you deploy objects via DACPAC or schema compare using tools like Azure DevOps or VS Code, giving you full control over versioning and avoiding Fabric’s Git quirks altogether.
Better Together - the Lakehouse and Warehouse - Microsoft Fabric | Microsoft Learn
Lakehouse end-to-end scenario: overview and architecture - Microsoft Fabric | Microsoft Learn
Lakehouse deployment pipelines and git integration - Microsoft Fabric | Microsoft Learn
Solved: Share warehouse/lakehouse between Workspaces - Microsoft Fabric Community
Solved: Re: GIT integration with Lakehouse not working thi... - Page 2 - Microsoft Fabric Community
Best Regards,
Lakshmi
Hi v-lgarikapat,
Thank you for your response and help. Since my initial post, we've tried a few scenarios and decided to house data stored in their own workspace (workspace dev 1), and have operational activities, like data pipelines and notebooks in another workspace (workspace dev 2). Still adopting the use of environments, but each environment will have two workspaces associated with it. Then, when devs pull code from workspace dev 1 only, they are only pulling operational artifacts. Using shortcuts proved confusing for Fabric when branching and pushing code to the develop branch, due to Lakehouses not being supported by git currently. We also didn't like the fact that the data in tables get deleted each time a table change is merged from a feature branch into develop.
Using this approach, we can:
* Create views and stored procedures in the data warehouse on data in the lakehouses, without having to use shortcuts.
* eliminated the issues we were encountering when branching code from the develop branch/ workspace into another branched workspace.
* still use version control and the PR process in git on the operational activity code.
* version control the data warehouse and SQL server db, by having it on another branch.
Hi caseybks ,
Thank you for sharing the resolution. I truly appreciate your effort this will be very valuable and helpful for other community members as well
We appreciate your collaboration and support!
Best regards,
Lakshmi.