Forum Discussion
Views in Warehouse Breaks Source Control Sync
If we had selective sync on the normal workspace branch binding, that could allow us to provide a decent workaround to the sequencing problem (as well as solve for a bunch of other gotcha moments we've experienced with git update). As for now, we've abandoned the idea of supporting warehouse objects in our Fabric environment until the CICD story around it is more sound. Instead, we have pushed the views back up to being the responsibility of the consumers even though this means the views would be defined multiple times across the various consumers. Not ideal...but this is our Plan B workaround to this problem for the moment. I appreciate some of the insight you all have given on level of maturity on this asset and possible workarounds to consider.
Continued ContributorHi kozman ,
One middle ground that might beat duplicating the views across consumers is keeping those cross-item views out of the Warehouse's Git definition entirely and deploying them as a post deployment step. Store them as a single .sql file in the repo, then after the workspace syncs and the Lakehouse is populated, run that script against the Warehouse from a pipeline Script activity or a small notebook. You still get one definition in source control, and the order problem goes away because the script only runs once the tables exist.
If you'd rather keep everything in the Git sync, another option is a bootstrap notebook that creates empty Delta tables with the right schema in the new Lakehouse first. Once the tables exist, the Warehouse update can resolve its dependencies, and real data can land later.
Neither is as clean as selective sync would be, so definitely worth adding to Fabric Ideas too.