Forum Discussion
Helper Icomposite model and deployment Pipeline meta data refresh issue
Raki39 This works by design - The Model's schema in QA is similar to that in Dev, and it still uses the PRODUCT table (even though the data source doesn't have it). Deploy does not erase existing data, so either the new data source have all the tables the model is using, or add a parameter (again controlled by a rule) that somehow in the model prevent using that table.
Microsoft EmployeeHi Raki39
If I understand right the scenario, then this is by design.
Deployment pipelines pairs two items across neighbour stages so then on future deployments, it knows which item to override on the target stage. The pairing process is done based on the combination of item type+name while in case of conflict, the item's full path (workspace folders) will be considered as well.
With that, it seems like your semantic-model items on Dev and QA are paired, and same is for those on QA and Prod, since they have the same name and item type. Once paired, the item on the target stage will be overwritten, regardless if it has the same tables or not as its source. Fully compare of 2 paired items is only done as part of Deployment pipelines' compare process which in the end presents indidcation of the target item vs. its source item.
Best regards,
Lee
Helper IThanks For the explanation LeeBenjamin
Despite refreshing the semantic model data with the QA/PROD source after deployment, the metadata isn't updating. Consequently, columns or tables not present in the QA and Prod data sources remain visible in the semantic data model for both environments. Is this expected behavior within a deployment pipeline when using a semantic model? It's worth noting that we've successfully deployed multiple reports with direct Power BI datasets using live connections through the deployment pipeline without encountering this issue, the deployment pipeline without encountering this issue,
- LeeBenjamin
Raki39 This works by design - The Model's schema in QA is similar to that in Dev, and it still uses the PRODUCT table (even though the data source doesn't have it). Deploy does not erase existing data, so either the new data source have all the tables the model is using, or add a parameter (again controlled by a rule) that somehow in the model prevent using that table.