Branched workspaces: Creating Views in the Datawarehouse that reference a Lakehouse table

[caseybks]

Hi,

My team is trying to work with branched workspaces, backed up by the git integration.

We have our development workspace, which is connected to the develop branch. Then, each developer branches off into a new workspace to develop privately in their own branch and workspace. 

What we've found that works up to now:

• datawarehouse, sql db, notebooks, datapipelines are all backed up by git
• you can merge new tables, views etc in the warehouse from your branched workspace.
• we have found that when we build pipelines and notebooks using existing tables, creating new table or using Lakehouse data, we need to reference the lakehouses in the development workspace, and because its not backed up by git, when we merge, there is no errors or issues.

What we are finding challenging & need help with is in our development workspace, we have a lakehouse and datawarehouse. We would like to create a View or a Stored Procedure that references a Lakehouse table. When a workspace is branched, the lakehouse is empty (as described in the documentation), so to get around this, we created some shortcuts to the development workspace Lakehouse table from a branched workspace, so that a view could be created in the branched workspace datawarehouse and then merged into the development workspace/ develop branch. First off, we got errors due to shortcuts having the same names as existing development Lakehouse tables. Therefore, we removed the shortcuts from the develop branch and decided not to commit shortcuts from branched workspaces, which could easily be done. However, we found that when new developers pulled code or branched off to a new workspace, with a view referencing a Lakehouse table, this caused errors in the new branched workspace as there was no shortcut or Lakehouse table to reference, and was just not workable.

So, I next resorted to removing the datawarehouse from the git versioning by adding the datawarehouse's repo path to the .gitignore file e.g. 'datawarehouse.Warehouse/'. This works when I have the repo open locally in VS code, however, in the Fabric UI when something is changed in the datawarehouse, we still get a Source Control Changes alert icon appear, with the option to commit. The develop branch is protected, as we'd like to use the PR process to merge code.

So it seems that the .gitignore file is not being recognised either, which is frustrating. Is this right? Or am I doing something wrong? If this option worked then we were just going to control the datawarehouse deployments with its own db project deployment.

I know in the forum and documentation, people recommend creating lakehouse tables in their branched workspaces to be referenced, however, this just does not seem feasible when you have 1000s of lakehouse tables to reference. 

Any recommendations or guidance on this would be most helpful.

Thanks!

[BhaveshPatel]

This is recent addition of VIEWS in Delta Lake. Now Databricks Delta Lake = Microsoft Fabric SQL

[v-lgarikapat]

Hi @caseybks ,

Thanks for reaching out to the Microsoft fabric community forum.

@BhaveshPatel  

Thanks for your prompt response

@caseybks  

 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

[v-lgarikapat]

Hi @caseybks ,

We haven’t heard back from you regarding our last response, so I just wanted to check in to see if you were able to resolve the issue. If you have any further questions or need assistance, please feel free to let us know.

Best Regards,

Lakshmi

[BhaveshPatel]

 Hi @caseybks 

There are views in Fabric DataWarehouse. you can find Tables only that are generated from data lake ( apache spark ) and delta lake. You can connect with me in Linkedin ( https://www.linkedin.com/in/bhavesh-patel-472829106/ ) and I will go through each and individual steps of Delta Lake. Cheers


This is what we have done so far and it is successful outcome project.

Bronze Tables -- > Silver Tables -- > Gold Tables. All these is happening in In memory engine of Delta Lake.

[caseybks]

Hi @BhaveshPatel, thanks for your reply, but you can create Views in Fabric datawarehouse.

A simple example is:

CREAT VIEW datawarehouse.dbo.view

AS 

SELECT* FROM lakehouse.gold.table1