Forum Discussion
Share your thoughts on DirectQuery for Power BI datasets and Azure Analysis Services (preview)
tessahurr A big thank you and congratulations to the team for making this a reality. It's hard to overstate the impact of this.
We've had some of the same issues that others have reported, but some signouts/sign-ins on PBI desktop seem to have gotten us around that.
One of the big things that come to mind which I'm glad you've mentioned is governance. This issue is basically still there with any live-connected Power BI model, but composite models make this more important. Basically, how do we best insulate ourselves from breaking changes when connected to a live connection or derived model? Is the long-term vision to have customers rely only on naming conventions, or can we have something more robust?
Use case:
My Power BI model, connected to an Azure AS data source, has a measure called [Total Sales]. Later on, someone determines that this is a very useful measure to have in the base Azure AS model, so [Total Sales] is brought into the base model. The original Power BI model then breaks because there's now a duplicate measure defined. So, we tell our users to use a naming convention to prevent this. Maybe we put out an edict to our users to always prefix their own measures with u -- we tell them not to create [Total Sales], but instead [uTotal Sales]. Then, of course, they're renaming all of their columns in all of their visuals from our naming-convention based measure name to a more human readable measure name. Yuck.
Coming from the programming world, we use namespaces to solve this sort of problem. If we could give a namespaces to our base model(s) and reference those in our derived models, that could be a great solution. Sounds like it'd be a pretty huge change for the parser/engine, but it could be quite useful.
How this would work in practice is, I admit, non-trivial, especially when trying to balance the needs of casual and line-of-business users. Making that experience user-friendly and developer-friendly could be somewhat of a challenge, but for those of us who run "big, centralized model" shops, it's a question we've been actively thinking about.
- jeroenterheerdt5 years ago
Microsoft Employee
we are looking at the lineage view and impact analysis to cover this, but yes, there is more to done in this area.
- dmarkle5 years agoFrequent Visitor
Yeah, I think my follow-up on this is whether or not the team plans to do work in truly preventing derived model breaks, or if the thinking is just about detection. Granted the former is a heavy lift, but I think it's worth doing, or at least talking about. Actually scoping measure names to the tables they're assigned to could also work; an upstream model could reserve a measure table solely for its own use....