I'm not sure about the ad-hoc data views use case. I cannot find any rationale behind it in documentation. For now I have a lot of problems as many of lens/visualisations from integrations are using them, then I cannot change it in one place to include, i.e. remote clusters data there. Wouldn't it be more rational for these ad-hoc views to be based on those persistent ones to be more composable and to have single-point-of-control for base scope selection?
Maybe I misunderstood something and there is already convenient way to manage those relations. Could someone advise me on this topic?
Hi @tancredi . Just wanted you to know that the team saw your feedback.
Ad-hoc data views are used in many programmatic scenarios in Kibana (e.g. apps creating hidden data views behind the scenes to power specific embedded visualizations).
However, I think your feedback is targeting the user-created ad-hoc data views in particular.
From that perspective: since the data view menu surfaces all library data views, users were ending up with a lot of clutter, as well being reluctant to create new data views for specific objectives.
The thinking was that users might have use for a temporary data view during data exploration without committing it to the global data view picker.
Another case is that you may have a bespoke visualization that uses specific runtime fields or a special index pattern (for example) without necessarily needing/wanting to reuse that configuration elsewhere.
That said, you aren't the only one who has been interested in some sort of middle ground or at least a smoother relationship between the two types of data views.
Other ideas have included added the ability to promote ad-hoc data views to library data views or the possibility to reuse ad-hoc data views among panels on the same dashboard.
To sum up, I think there's work to do to polish this UX further, but hopefully that gives you some insight into why these exist. Thanks for posting your feedback.