This page does not yet show the New LookML IDE, which suggests parameters and values as you type, on-the-fly error checking, a context-sensitive help pane, automatic formatting, and the ability to fold sections of code. For more information about these features, see this article. The following page is still useful to introduce some additional concepts, including how to run the LookML validator on your completed code.
Creating and Testing New Fields
As an example of editing LookML, we'll add several fields and then test them.
Creating a Dimension
First we will add a new dimension to our
users view that determines if a user is from either California or New York. The dimension will be
type: yesno, which means it will return Yes if the user is from California or New York, and No if not.
The LookML for our new dimension looks like:
Add this dimension to the view file for the
users view. Click Save to save your changes.
Check out substitution operators to learn more about
Creating a Measure
Next we will add a new measure to our
user view that averages the age of our users. This measure will be
type: average and aggregate over the column
The LookML for this new measure looks like:
Add this measure to the view file for the
user view. Click Save to save your changes.
Testing the Fields in Explore
We can now test our new dimension and measure by querying them. After saving your changes, these fields will appear in the field picker in Explore. An easy way to access the Explore for the current view is to use the dropdown menu next to the view file name:
Once we are in the
users Explore, we can select the new fields to add them to a query. A query with both the new fields shows the average age of users who are from California or New York, versus users who are not:
Note: you must be in development mode to access these new fields until you have commited and pushed your changes to production.
Validating Your Changes
When you are satisfied with your changes, you can use Looker's validation tools to ensure that your changes will work correctly.
Looker provides a LookML Validator to provide validation of your LookML code before it is published to the production environment. Although it will not catch every issue, it will prevent a great deal of errors.
The LookML Validator should not be confused with the Content Validator, which instead checks to see if the changes you've made will break any saved Looks.
To run the LookML Validator, click the Validate LookML button above the file list in the Looker IDE:
This will display a list of errors and other warnings that you should address:
The validator button will become available again if you make and save another change or fix:
No LookML Issues
When there are no issues found by the validator, you will receive the No LookML Issues message in green.
LookML errors are issues that could prevent queries from running. The number in parenthesis is the number of errors found (one error below):
Within the expanded list of issues you will see the reason why validation didn't pass. Often times, if you click on the error, it will bring you directly to the problem row of code. You'll see a red "X" next to the row. Hovering over it will provide more detailed error information in some cases:
Chat Team Tip: The validation error we are asked about most is “Unknown or inaccessible field.” Check out this article for the causes and what to do about it.
LookML warnings may not necessarily prevent a query from being run, but may still result in broken or unintended functionality for your users. As with errors, the number in parenthesis is the number of warnings found (34 warnings below):
As with LookML errors you can expand any warnings, jump to the problem code by clicking on them (in many cases), and hover over the exclamation point icon for more information:
LookML Deprecation Warnings
LookML deprecation warnings alert you to the fact that you're using LookML parameters that have been phased out in favor of others. While your project will still function for the time being, eventually these parameters will be turned eliminated, which will result in future problems. It's best to update parameters as you go to avoid creating an urgent, large amount of work when they are eliminated.
As with errors and warnings, you can expand deprecation warnings and jump to problem code by clicking on them (in many cases).
Deploying your Changes
After you've validated that your changes will work properly, you can use Looker's git integration to commit and push your changes to production.