Looker 5.14 Release Notes


(Carter Moar) #1

Anticipated Deployment Dates

Release Rollout Begins: May 6, 2018
**Release Final & Download Available:**May 17, 2018

Release Highlights

In addition to general tweaks and enhancements, this release comes with new and improved features in the following categories. Read on for more detail.

Preparing for Release

Please take notice of items marked with a :zap: as they indicate changes to existing functionality and may require your attention. For more information see Features by Section below.

Notable Features

Data Privacy and Compliance Features

This release we’re changing the way we do privacy with a new suite of features designed to protect our users’ data and to make it easy for you to do the same. Administrators can now opt in to a “Cookie Notification Banner” to comply with new EU GDPR requirements and edit disabled SSO and LDAP users’ data, ensuring that disabled users’ privacy remains protected. Email subscriptions are now managed in the Preference Center rather than on users’ Account page.

New and Improved Scheduling

We’re introducing a brand-new scheduling modal designed to make scheduling your Looker content even easier and more intuitive than before! Basic, common settings are presented in an image-rich format for quick navigation, while more advanced settings are now hidden in a special advanced settings menu geared toward administrators and technical users.

Experimental Custom Fields

Create dimensions and measures in real time without additional LookML development with Looker’s new experimental Custom Fields Labs feature. Designed to be a solution for non-developers who need a new field fast, but don’t want to dig deep in the LookML, Custom Fields use table calculation syntax to create fields that are groupable, sortable, and pivotable for even easier deep data dives. Please note that this is an experimental Labs feature and will require some special administration to enable. Since it is an experiment, the Custom Fields may not make it in to Looker in their current form, or at all.

Features by Section

Platform and Administration

  • Cookies Notification Banner. Added a toggle in the Admin menu to include a cookies notification banner to all users on a Looker instance.
  • :zap: Email Subscription Changes. Removed all email subscription options from user menus. Users will now be able to manage their subscription preferences in the Preference Center linked in their Account Page.
  • Edit Disabled LDAP and SSO users. Introduced functionality allowing administrators to edit disabled LDAP and SSO users.
  • Updated Cached Data Retention Policy. Looker has significantly reduced the time to clean up cached encrypted query results when the Instant Dashboards Labs feature is not enabled.

Dashboards, Visualizations, and Exploration

  • :alembic: [Labs] Experimental Custom Fields. New experimental feature allows for on-the-fly field creation without additional LookML modeling. Try it on Next. Learn more about setting up the experimental group.

  • Improved Mapping Functionality and Added New Maps. Including a satellite map, a traffic map, label visibility control, and more.

  • :zap: If you’re running your instance behind a firewall you may need to whitelist mapbox.com, as the maps are no longer pointing to lookecdn.com.

Scheduling and Downloading

  • New Scheduler Modal.
  • Increased Email Size Limit. Email size limit has been increased to 15mb.
  • :alembic: Looker API 3.1 API 3.1 endpoints and functionality are now available for experimentation in the interactive Looker API docs. Learn more.

LookML and Development

  • :zap: The LookML Validator will now correctly include a warning when ${} field references are included in SQL-based Derived Tables. Note that it is not currently possible to reference LookML fields from a Derived Table; in previous versions Looker had silently ignored the ${} characters if they referred to fields.
  • Git Garbage Collection. Looker will now periodically perform garbage collection on all project repositories via git gc. This will speed up most Git operations done within Looker, especially in larger projects.

General Tweaks and Bug Fixes

  • Dashboards, Visualizations, and Explore
    • Fixed a bug where disabled series in certain visualizations were not saved to dashboard tiles.
    • Fixed a bug where the order of visualization options was wrong in explore toolbar.
    • Fixed a bug where some visualizations with table calculations were showing null values.
    • Fixed a bug where series label changes did not save to non-cartesian graphs.
    • Fixed a bug with swapping between time and ordinal data on the X-axis.
    • Fixed a bug where index() table calc function was broken.
    • Fixed a bug where explore field menus were cut off at bottom of page.
  • LookML and development
    • Fixed a bug where importing any LookML dashboards into a Space would import all LookML dashboards into that Space.
    • Fixed a bug where some PDTs were failing to build in the correct order.
    • Fixed a bug with datagroups lacking a max_cache_age.
    • Fixed a bug where incorrect LookML was being generated from a dashboard.
  • Content Management and Discoverability
    • Fixed a bug where add to dashboard button had disappeared.
  • Scheduling and Downloading
    • Fixed a bug where editing scheduled plan filters did not save.
  • Dialects
    • :zap:Data Virtuality drivers are no longer bundled with the Looker .jar. Self-hosted customers will have to add a driver to their Looker machine. Learn more.
  • Platform and Administration
    • Fixed a bug where it was not possible to delete users that were no longer editable.
    • Fixed a bug where connection test was resulting in a false negative.
  • Security
    • Introduced the ability to escape values in CSV files that might be interpreted as formulas or macros in common spreadsheet applications.
    • Added clickjacking protections for Looker login pages.

Mapbox error 5.14.16
(Carter Moar) #2

(Ian) #3

These custom fields seem cool but how do they work?
They must be saved against the model somehow right in order to be taken into consideration for the construction of the query?

(Carter Moar) #4

Technologically speaking, they’re basically a mechanism to construct a query by using our expressions (Table Calculation syntax) rather than by writing LookML. I’ve been messing around with them here and there and have been thinking about them as Table Calculations that write directly to the SQL for a query.

We’re hoping to have a module up in What’s Next by the end of the week to get you started without having to do any configuration on your instance. To get them going on your own data, you’ll need to set up a special Group so that your mad scientists can keep their experiments isolated. Instructions on that set up are here.

We’d love to get your thoughts if you do start playing with them–the feedback will determine their final form!

(Carter Moar) #5

A quick update for you, @IanT: we’ve got a little example to play with up on Next that you can play with without having to set it up on your own instance.

(Tig Newman) #6

@IanT ,
I’ve just rolled out some documentation pages on creating, editing, using, and deleting custom fields:

(Kenny Wu) #7

Thanks for the explanation!

Going to be testing this out very soon: we’ve had a use case around power users needing to create new custom fields to regroup items based on existing fields. Calculations were a passable hack to do this, but this sounds way better.

A couple questions (these may become obvious once we get into playing around with the feature):

  1. Performance - how well does this scale and will (or when will) we see performance trade offs?

We’re thinking about using this to give our power users a way to define fields, but want to know if we should be planning to have our devs follow up and build fields into LookML for real.

  1. Sharing / Visibility - can users share custom fields with others?

(Carter Moar) #8

For the foreseeable future there won’t be a way to push Custom Fields back to the model. So they maybe a good prototyping tool for your power users, but you’ll still want some devs to graduate those fields to the model for permanent, broad availability, and to make them canonical.

Speaking of availability, only those in the beta group will be able to create Custom Fields, but anyone can be sent a query that makes use of them. They behave basically the same way Table Calculations do–they’re impermanent, but hang around in a query slug so sharing is possible.

As for performance, the expressions are sent to the SQL for a query so they’ll be less machine-intensive than Table Calculations, but you’ll have to wait for the database to return results if they aren’t already cached.