As of Looker 3.38, the
decimals parameter as well as the
int field type are being deprecated and moved to the Admin > Legacy Features panel.
The reason for these deprecations is to simplify how Looker handles number values by providing a single field type (
number) and a single, flexible way to format them through Excel-style format definitions.
Starting in 3.38, the
decimals parameter is deprecated. It will continue to work so long as the LookML “decimals” Parameter and “int” Field Type legacy feature is turned on, but each occurrence in a model will produce a deprecation warning in the LookML Validator.
The new way to format numbers is with either the
value_format_name parameter (see below).
2. Deprecated value truncation when
decimals is not specified
Prior to 3.38, a
number field that did not specify
decimals would truncate the number value to zero decimal places. (i.e 0.535 would become 0).
This could result in misleading queries and developer confusion. To remedy this,
number fields will now show the entire number as returned by the databse by default. To format the number differently, use
This change in behavior is also controlled by the LookML “decimals” Parameter and “int” Field Type. Disabling this legacy feature allows this new, clearer default behavior.
int field type
Starting in 3.38, specifying
type: int on a dimension or measure is deprecated. It will continue to work so long as the LookML “decimals” Parameter and “int” Field Type legacy feature is turned on, but each occurrence in a model will produce a deprecation warning in the LookML Validator.
type: number should be used instead.
The purpose of the
int field type was to show number values with no formatting (thousands separators) or decimals, as is often desired for ID fields. Since deprecating
type: int in favor of
type: number, Looker is now smart about whether or not to show thousands separators and decimals by default based on the name of the field. If the field name is
id, ends with
_id, or if
primary_key: true is set on the field, no thousands separators or decimals will be shown.
If a field should not have thousands separators or decimals but does not follow one of the above patterns, the equivalent of
type: int can be achieved by using
type: number with the
id value format:
- dimension: my_cool_dimension
See below for more information on the
The proper way to format numbers is with value formats. A value format can be defined on the fly for a field with the
value_format parameter, or a named value format can be defined and referenced by multiple fields via the
The syntax for defining a value format in LookML is the same as for Excel. Example:
- dimension: order_profit
This will cause all
order_profit values to be displayed with thousands separators (commas) and one decimal place.
value_formats and the
If a format is used for multiple fields, it can be helpful to define it once and simply refer to it by name whenever it is needed. This is done in a model file as follows:
- name: telephone
value_format: "(###) ###-####"
Then to use this named value format for a field:
- dimension: phone_number_formatted
Looker also provides the following set of built-in formats:
|id||number with no commas||0||1234|
|usd||U.S. dollars w/ cents||$#,##0.00||$1,234.56|
|percent_0||percent w/ 0 decimals||#,##0"%"||12%|
|percent_1||percent w/ 1 decimal||#,##0.0"%"||12.3%|
|percent_2||percent w/ 2 decimals||#,##0.00"%"||12.34%|
|percent_3||percent w/ 3 decimals||#,##0.000"%"||12.345%|
|percent_4||percent w/ 4 decimals||#,##0.0000"%"||12.3456%|
“%0A” actually does not work. It shows correctly the newline on a search page, but then when I press Replace, the newline does not make it into the files.
For now we are using some simple logic to determine if the field is an ID or not. In the case that we believe it is an ID we will not show commas or decimals.
A few of the things we use to determine this are:
If you can think of any other cases we should take into account we are definitely open to suggestions!
What is the logic around decimals and the field name? Does Looker automatically show decimals for all fields not identified as IDs? If not, can you detail the logic? We could go through and test these but it would be easier to bulk convert our integer fields.
Some common ID string alternatives you might want to consider adding
(all are some variation of a standardized ID code)