The ultimate Fabric, Power BI, SQL, and AI community-led learning event. Save €200 with code FABCOMM.
Get registeredEnhance your career with this limited time 50% discount on Fabric and Power BI exams. Ends August 31st. Request your voucher.
When branching out a workspace under source control to feature workspace and the orginiating workspace has a Fabric Warehouse the logicalId in the .platform file is not the same after the feature branch workspace has source control change (they happen anyway) committed. This cause issues in being able to manage merging changing back from the feature workspace. This does not seem to be the case for other item types such as Notebooks where the logicalid is the same accross the orginating workspace and the feature branch workspace.
Is this the expected behaviour and if so why?
It appears we may need to not commit any warehouse changes to avoid misalligned logicalid in the feature workspace and then download a database project and progress changes in a very unconventional manner.
Does anyone have any suggestions to provide insight on alternative approaches?
Fabric Warehouse logicalId: (string) An automatically generated cross-workspace identifier representing an item and its source control representation. It appears this is not the case when branching out to feature workspaces for fabric warehouse - why not?
Solved! Go to Solution.
Hi @royclack , Thank you for reaching out to the Microsoft Community Forum.
Yes, the logical ID mismatch for Fabric Warehouses when branching to a feature workspace is expected behaviour due to how Fabric provisions Warehouses as new runtime instances with compute/storage backing in each workspace. Unlike Notebooks, which retain their logical Id as simple definitions, Warehouses generate a new logical Id in the feature workspace, causing merge issues when committing changes via the. platform file. This happens because Fabric treats Warehouses as stateful, managed SQL databases, not just portable artifacts.
To work around this, avoid committing Warehouse changes directly from the feature workspace, use a SQL database project to manage schema changes locally, committing them to Git and syncing back to the originating workspace and consider deployment pipelines for a more robust lifecycle.
If this helped solve the issue, please consider marking it 'Accept as Solution' so others with similar queries may find it more easily. If not, please share the details, always happy to help.
Thank you.
Hello!
I dont think this is intended behaviour as @tkoeman mentions, I will create a new topic about this issue.
Thankyou, it's interesting how things are evolving...overtime...and seeing this blog which is perhaps lakehouse centric Optimizing for CI/CD in Microsoft Fabric | Microsoft Fabric Blog | Microsoft Fabric
As seperate point we're driving our metadata from outside the Fabric ecosystem using SQL and have not adopted Fabric SQL. I will check-out Fabric SQL in case it works similarly to a Warehouse. We have a Lakehouse/Warehouse setup currently so this is our long-term area of interest too.
Hi @royclack , Thank you for reaching out to the Microsoft Community Forum.
One thing that might help is starting with your Warehouse schema changes in a local SQL environment, something like SSMS or Azure Data Studio. It gives you a safe way to test and validate your updates without dealing with workspace-specific issues in Fabric. Since you're already driving metadata from outside Fabric, this keeps things consistent with your current process.
You might also want to take a look at the Fabric SQL Endpoint. It gives you a unified T-SQL layer over both Lakehouses and Warehouses, which could make your external SQL workflows a lot smoother. It doesn’t replace a Warehouse, but depending on how you're querying and managing metadata, it could help reduce how often you need to touch the Warehouse runtime directly.
And finally, for deployment, you could set up environment-specific SQL scripts (for dev, test, prod) and use something like GitHub Actions to run them selectively as part of your CI/CD. That way, you're keeping the schema logic outside of Fabric’s runtime, which makes your deployments more predictable and easier to manage across workspaces.
If this helped solve the issue, please consider marking it 'Accept as Solution' so others with similar queries may find it more easily. If not, please share the details, always happy to help.
Thank you.
Hi @royclack , Thank you for reaching out to the Microsoft Community Forum.
Yes, the logical ID mismatch for Fabric Warehouses when branching to a feature workspace is expected behaviour due to how Fabric provisions Warehouses as new runtime instances with compute/storage backing in each workspace. Unlike Notebooks, which retain their logical Id as simple definitions, Warehouses generate a new logical Id in the feature workspace, causing merge issues when committing changes via the. platform file. This happens because Fabric treats Warehouses as stateful, managed SQL databases, not just portable artifacts.
To work around this, avoid committing Warehouse changes directly from the feature workspace, use a SQL database project to manage schema changes locally, committing them to Git and syncing back to the originating workspace and consider deployment pipelines for a more robust lifecycle.
If this helped solve the issue, please consider marking it 'Accept as Solution' so others with similar queries may find it more easily. If not, please share the details, always happy to help.
Thank you.
Working with a Fabric Warehouse used to work fine with me until about a week ago. The warehouse is synced to Git with it's own unique logical id saved in the .platform file.
Now when I connect a feature branch to an empty workspace and update from Git, Fabric decides it does not like this logical id and generates a new one. My colleagues don't have this problem (yet), but I'm afraid they will when they would sync their feature workspaces from scratch.
This very much looks like a problem that was present about 10 months ago: Warehouse Branching : r/MicrosoftFabric and was solved afterwards and is somehow reintroduced now again.
This does not look like it's intended behaviour!
As for the workaround: I don't see how I could prevent these changes from being synced to the branch. As far as I know Fabric does not support the .gitignore included in my project, so how would I go about using a SQL database project to store the database definitions and don't have them committed to the Warehouse?
User | Count |
---|---|
2 | |
2 | |
1 | |
1 | |
1 |
User | Count |
---|---|
5 | |
4 | |
3 | |
2 | |
2 |