Querying dimensions without metrics

[courtneyholcomb]

Completes #SL-949

Description

Enable querying for dimensions without metrics.
If a user submits a query with dimensions and not metrics, we'll assume they want the distinct values for those dimensions.
This PR adds a new DataFlowPlan for distinct values that will allow those queries. The plan is essentially a simple ReadSqlSourceNode -> optional JoinToBaseOutputNode -> FilterElementsNode.
For simplicity's sake, I added an attribute to FilterElementsNode called distinct to indicate if we should group by the filtered elements (therefore getting the distinct values). I updated the costing for that node to reflect an aggregation in that case.
A lot of the other changes here are just renaming or restructuring things to not assume that metrics / measures are included in the query, and removing errors that enforce that requirement.

Note: something is up with the Databricks credentials, so I still need to fix that & update those snapshots.

[tlento]

Ok, let's go with this!

There are no blocking concerns but I do have a lot of small quality considerations that we should address one way or another in the very near future.

Whatever you feel is worth fixing prior to merge, please go ahead and update. I'm happy to take another look if you'd like, but I don't need to.

After merge I'll go through and file issues for whatever follow-ups we still need to make.

Thank you!

[tlento]

Checkpoint, this must be changed in a later commit one way or the other.....

[courtneyholcomb]

What do you mean??

[tlento]

This feels like potentially a lot of iterating through datasets to me since we'll call this function once for every partial time dimension spec, but I think it's fine for now.

[courtneyholcomb]

Yeah, it would probably be better to create a dict of time dimension instances to their output datasets on init (or something like that) so we only need to do this loop once. Not sure how complicated that change will be, let me look into it and see if it's worth doing before merge

[courtneyholcomb]

FWIW, it turns out we are caching the output dataset so get_output_data_set() is just a dictionary lookup after the first call for a given node!

[tlento]

Ok. I think it might be better to keep this totally separate from the new function and branch at the callsite for now.

There are only two callsites, one of which is in this class, and that way we aren't tempted to keep adding responsibility to the node output resolver.

What do you think? Otherwise it might be worth it to mark the new method with the leading _ for the time being, I'm not sure we'll ever really want to call it on its own if we keep this method signature.

[courtneyholcomb]

Not totally sure I understand what you mean. Is it this? We don't want to use the node_output_resolver here, so we should pass in the output datasets already resolved.

I'm thinking maybe it would be better to do this all on init for this class. Iterate through all the datasets and store a dict of all time_dimension_instances to a set of supported granularities. Then it will be super easy to grab that at query time.

[courtneyholcomb]

^ implemented it this way!

[courtneyholcomb]

Note that Databricks is failing due to connection errors unrelated to this PR.

[kingduxia]

Can mf query support this feature?

mf query --where "name==Gerald" --explain
⠙ Initiating query…
ERROR: Unable To Satisfy Query Error: Recipe not found for linkable specs: LinkableSpecSet(dimension_specs=(), time_dimension_specs=(), entity_specs=())

mf --version
mf, version 0.203.1

how to add specific dimension or entity in query?

[courtneyholcomb]

@kingduxia use the --group_by flag.

Please use the community slack for future questions.