Fix hack for legacy Metrics Views #5866
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
A file specifying a legacy Metrics View generates 2 resources: a Metrics View and an Explore. However, the
FileArtifact
class (which impacts much client-side code) makes the assumption that a file is associated with 0 or 1 resource.In the
FileArtifact
class, for legacy Metrics View files, we've added a hack so that we ignore the generated Explore resource.Problem
The original hack wrongly ignored the Explore resource for Explore files placed in the
/dashboards
directory. (Because we previously assumed that any file placed in the/dashboards
directory was a legacy Metrics View.)Solution
The new hack identifies when an Explore resource is associated with a legacy Metrics View by checking to see if the file is already associated with a Metrics View. This should work because, for legacy Metrics Views, the parser first creates the Metrics View and second creates the Explore.
(In the long-run, it'd be nice if we could remove the assumption that a file generates at most 1 resource.)