When deploying Direct Lake semantic models via Deployment Pipelines, the Lakehouse source is incorrectly treated as an external SQL source. This results in broken lineage and prompts for credentials.
Even when using deployment rules to update the SQL endpoint and database ID, the semantic model does not re-bind to the Lakehouse in the target environment.
Expected behavior:
Deployment Pipelines should natively support Direct Lake re-binding, maintaining proper lineage and avoiding unnecessary credential prompts.
Current workaround:
Using the semantic-link-labs library to rebind the semantic model programmatically post-deployment.
3 Comments
agusmbaAdvocate III
Likewise for DirectLake (OneLake) semantic models. There is no auto-binding to the equivalent lakehouse on the destination workspace nor deployment rules to manually configure the rebinding.When developing Semantic Models and promoting through a normal Git flow where each shared workspace represents Dev, Test and Prod, the Lakehouse reference in expressions.tmdl file needs to reflect the Lakehouse of the same workspace. Right now, we needed to create CICD hook that changes the address after merging up to staging and main branches and check those changes in so that we are not constantly breaking the sem models every time we promote changes. This has the inverse effect that the code in git is always be out of sync between feature branches, staging and main branches. Allowing for variable library reference in the expressions.tmdl for the address would be the obvious choice to solve for this.
To me the rebinding gap is a fundimental problem for using Fabric for an enterpriese level analytics system. To not be able to use a deployment pipleline without workarounds when have a semantic model connected to a warehouse seems like a major oversight.
