Add SQL validator support for measures

[DylanBaker]

Change description

Adding support for measures in the SQL validator

Type of change

• Bug fix (fixes an issue)
• New feature (adds functionality)

Related issues

Closes #368

Checklists

Security

• Security impact of change has been considered
• Code follows security best practices and guidelines

Code review

• Pull request has a descriptive title and context useful to a reviewer

[jschintz-windriver]

Thank you!

[joshtemple]

A few high-level questions:

1. Aside from allowing measures to flow through into the LookML tree, is there anything else special happening to test them?

2. I'm not seeing any tests specifically for measures, just the refactored existing tests.

3. Should we expect performance to be impacted by including aggregates in the Explore-level queries?

[joshtemple]

Noting that this is basically a breaking change as far as the API is concerned.

[DylanBaker]

Yeah, we would need to release this with a corresponding change in the app/UI. It will likely need to account for both dimension and field, given old runs will have the old key.

[joshtemple]

If a dimension LookMlField and measure LookMlField are compared, how are they marked as different? Is it the type attribute?

[DylanBaker]

Yeah, type should do it in most cases, but your question has made me realise that technically a dimension and a measure could both be of type number and have the same name. It's a very narrow case, but could happen.

There is a boolean measure field on the fields JSON payload, so we could easily add that to both the model and the eq function. Does that work for you?

[joshtemple]

Yes, that works!

[DylanBaker]

A few high-level questions:

1. Aside from allowing measures to flow through into the LookML tree, is there anything else special happening to test them?

2. I'm not seeing any tests specifically for measures, just the refactored existing tests.

3. Should we expect performance to be impacted by including aggregates in the Explore-level queries?

1. No, all we are changing is adding them when building the LookML tree. Everything else is unchanged except for renaming and the excluding measures functionality.

2. A number of the integration test results were changed to account for the new measures coming in. I also added new tests for excluding measures that have the original numbers. Happy to add more if desired.

3. I don't believe so. The only warehouse I'd be concerned by is Snowflake, given the weirdness of their query planner, but we would need to test. I'd recommend having people opt in to testing in the app (by having exclude measures set to true by default).

[joshtemple]

As far as measure-specific tests go, we may want to make sure all measure types are supported, since we don't have all of them defined on our eye-exam project.