Forum Discussion
Deployment Rules for Semantic Models - Change connection from DEV to TEST
- 1 year ago
LopesN ,
Thanks a lot for the update — and for sharing the PySpark workaround using semantic-link-labs, that’s super valuable for others who might hit the same wall.
From what you’ve described, it really looks like the Compare feature is holding onto some internal metadata reference tied to the original Lakehouse, and even after deletion + redeployment, it doesn’t fully reset.
Here’s a quick recap of what you tried (and a small tweak others might try too):
✅ What you did:
- Deleted the Lakehouse and all related Semantic Models
- Re-deployed from DEV
- Used this code to redirect the model to TEST:
%pip install semantic-link-labs from sempy.labs.directlake import update_direct_lake_model_lakehouse_connection dataset_name = "Lakehouse_Test_NLSM" # Name of the deployed dataset workspace_name = None # Optional: specify if needed lakehouse_name = None # Optional: specify if needed lakehouse_workspace_name = None # Optional: specify if needed update_direct_lake_model_lakehouse_connection( dataset = dataset_name, workspace = workspace_name, lakehouse = lakehouse_name, lakehouse_workspace = lakehouse_workspace_name )This is a solid approach — but unfortunately, as you said, Compare still fails, even with a clean redeploy.
🔍 What else to try:
- Try creating a completely new Lakehouse (with a different name) and deploy a fresh Semantic Model on top of it. If Compare works there, it confirms the issue is tied to internal lineage/cache on the original Lakehouse.
- If you’re comfortable, try using the Fabric REST APIs to inspect or reset lineage metadata (though this is more advanced and not always exposed).
- Definitely raise this with Microsoft Fabric support — this feels like a backend issue that needs cleanup on their side.
Let me know if you want help testing with a minimal setup — happy to assist.
If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.
*This response was supported by AI for translation and text editing purposes.
Hi LopesN ,
Yeah, I’ve seen this happen when using deployment rules to switch data sources in semantic models. The deployment itself works fine, but the Compare step breaks because it tries to diff the model against a version that now points to a different Lakehouse path or workspace.
A couple of things you can try:
- Go to the deployment pipeline settings and double-check if the rule is applied before or after the compare step. If it’s applied after, the compare might still be looking at the old connection.
- Try removing the rule temporarily and running Compare again. If it works, then re-add the rule and deploy.
- Also, make sure the TEST workspace has the same schema and metadata as DEV. Even small mismatches can cause Compare to fail silently.
This might be a limitation in how Fabric handles Compare when dynamic data source switching is involved. You can track known issues or raise a ticket here:
https://support.fabric.microsoft.com
Let me know if you want to test this with a stripped-down model to isolate the issue.
If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.
Translation and formatting supported by AI