Forum Discussion
Deployment Rules for Semantic Models - Change connection from DEV to TEST
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.
Hello burakkaragoz, thank you for your answer!
Regarding your points:
- 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.
A: I think the rules are applied before Compare, since after changing rule it detects changes from DEV to TEST - Try removing the rule temporarily and running Compare again. If it works, then re-add the rule and deploy.
A: I removed the rule but still doesn't work. And what is truly worst is that now I cannot use Compare with any other Semantic Models that use the same Lakehouse as source!
Without rules, it still points to DEV and as you can see in the following image, now even in this case I get an error, so if I want to use Compare feature, I would not be able to create Semantic Models from this lakehouse (which seems like a really bad news, since now I can't even "revert this" situation) - Also, make sure the TEST workspace has the same schema and metadata as DEV. Even small mismatches can cause Compare to fail silently.
A: Only Compare feature is failling, so if the schema is the same I cannot see that feature.
I need to force some changes (in my case I removed a table in DEV) so that Compare feature detects a change and shows the option to see changes (which is where the error is shown).
I will try to make some more tests but I'm not sure what further steps to take honestly.
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.
I have done some further testing but was not able to correct this issue.
I will create a ticket with microsoft to explore what the problem might be.
Thank you again for your feedback (and sorry for the delay in my answer)!