> ## Documentation Index
> Fetch the complete documentation index at: https://honeydew.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Looker

## Connection Setup

Create a connection and [set up JDBC parameters](/integration/bi-tools/looker#setting-up-a-new-connection) to configure a connection.

Use catalog to choose workspace and branch.

<Tip>
  Each workspace branch is a separate connection.

  Different branch connections can be used interchangeably with the same Honeydew explore.
</Tip>

### Metadata Sync

Looker relies on LookML views to query data. Honeydew can create LookML and synchronize all associated metadata.

Honeydew synchronizes the following metadata to LookML:

* Fields - every attribute in the field is defined as a Looker dimension, and every metric as a Looker measure.
* Field data types.
* Field display names (to `label` LookML field property). When no display name is set, Honeydew creates an automatic user friendly name.
* Field folders (to `view_label` and `group_label` LookML field properties). When no folder is set, Honeydew uses the entity name as folder name.
  <Tip>
    To fill the values for both `view_label` and `group_label`, you can use the following folder value format in Honeydew
    metadata: `Folder\Subfolder`. In this case, `view_label` will be set as `Folder` and `group_label` - as `Subfolder`.
  </Tip>
* Field hidden property (to `hidden` LookML field property).
* Field descriptions (to `description` LookML field property).

<Note>
  The recommended approach is use Honeydew to generate LookML. However, it is possible to use the connection directly and
  manually create a LookML view on top of it. Note that in that case the the continuous updates are manual as well.
</Note>

## Functionality

Honeydew supports Looker Explore over the shared semantic layer.

### Groups and Pivots

Any Honeydew [attribute](/calculations/attributes) can be used as a Looker dimension for groups and pivots.

### Measures

Any Honeydew [metric](/calculations/metrics) can be used as a measure (aggregation) in Looker.

<Tip>
  If you want to use a metric as a dimension, define it as a calculated attribute in Honeydew first.
</Tip>

### Filters

Any Honeydew attribute or metric can be used as a Looker filter.

Filters are automatically pushed down to the source in order to optimize performance.

### Cross-entity queries

Any entity in Honeydew can be used in an Explore.

Joins are automatically constructed by Honeydew. They are
based on the [relationships](/modeling/relations) between entities that are used in a particular user Explore query.

### Custom dimensions and measures

Custom dimensions such as binning, custom groups, unique value list dimension and Looker functions in custom field definitions are automatically converted to Honeydew attributes.

Custom measures such as an ad-hoc average or sum of a dimension are automatically converted to Honeydew metrics.

<Tip>
  If you want to reuse a custom measure or a custom dimension defined in Looker: save it in Honeydew to a named attribute or metric.

  That way, the code to compute it moves to the shared semantic layer.
</Tip>

### Explore configuration

Looker Explores can be based on [domains](/domains) in Honeydew.

Common Looker functionality maps to domains:

* Per explore filters (`access_filter`, `sql_always_where`, `sql_always_having` in LookML) can be modeled as [domain filters](/domains#filters).

## Domains

Honeydew [domains](/domains) can be mapped to Looker Explores.

Domains can be used to define centrally things such as:

* Access filters (instead using LookML such as `always_filter`)
* Customized join relations (instead of setting `join`-s in LookML)

To use a domain, use it as an explore source table, such as :

```yaml theme={null}
explore: supply_chain {
  view_name: world
  sql_table_name: domains.supply_chain ;;
}
```

## User attributes and Parameters

User attributes and parameters can be passed to [Honeydew parameters](/parameters) using the [parameter SQL interface](/parameters#using-parameters-within-a-sql-interface-connection) as part of an explore definition.

Looker user attributes and LookML parameters can be both used to pass down to an explore based on world or on a domain:

```yaml theme={null}
# pass $param1 and $param2 to Honeydew from different sources in Looker
explore: world_with_parameters{
  sql_table_name:
    (select *,
      {{_user_attributes['param1']}} as "$param1",
      {% parameter param2 %} as "$param2"
      from world.world);;
  view_name:  world
```

## Limitations

1. Filtered measures in an Explore over Honeydew metrics are not supported. Create a Honeydew [filtered metric](/calculations/metrics#filtered-metrics) instead.
2. Persistent Derived Tables (PDTs) are not supported. See [performance acceleration in Honeydew](/performance/overview) for alternative performance approaches.
3. Joins in an Explore between Views on Honeydew datasets are not supported. Instead, build a single Looker View with all the required entities, and Honeydew
   will figure out the needed joins.

## Setting up a new Connection

Looker connects to Honeydew via JDBC connection, using the **Trino** protocol.

<Info>
  The Honeydew JDBC connection translates Looker Trino SQL to Snowflake SQL.
</Info>

Looker connections are mapped to a Honeydew workspace and branch

<Tip>
  It is recommended to use an [API Key](/access-control/api-keys) for setting up the connection.
</Tip>

1. Go to **Create** and then click on **Connection**
2. Provide a **Name** for the connection (e.g. "Honeydew") and choose the desired **Connection Scope**
3. In the **Dialect** field, choose **Trino** from the list of supported dialects
4. Set **Host** to `jdbc.honeydew.cloud`

<Note>
  If your organization uses a custom hostname for the JDBC connection,
  you can locate it in the Honeydew UI, under the **JDBC** section in **Settings**.
</Note>

1. Set **Port** to `443`
2. Set **Database** to `<workspace>__<branch>` value, based on the Honeydew `workspace` and `branch` you would like to connect to.
   Omit the branch value if connecting to `prod`.
   For example, for workspace `tpch`, branch `prod`, the value would be: `tpch`.
   And for workspace `tpch`,  branch `dev`, it would be `tpch__dev`.
3. In **Authentication**, choose `Database Account`
4. Set **Username** to the API key (or a Honeydew username), and **Password** to the API secret
   (or to the user's password in Honeydew).
5. In **Optional Settings**, expand **Additional Settings**, and then switch on the **Verify SSL** toggle, if not already turned on.
6. Click **Test** to verify the connection settings
7. Click **Connect** to connect to the newly created Honeydew connection

You can now use the newly built datasource to [integrate Honeydew with Looker](/integration/bi-tools/looker).

## LookML

Use Honeydew to generate a LookML file.

The LookML for a Honeydew dataset will look similar to this:

```yaml theme={null}
## LookML code

view: customers_and_orders {

  # A specific dynamic dataset that applies its filtering
  # Can use world.world for the whole semantic world
  sql_table_name: dynamic_dataset.customers_and_orders ;;

  # String dimensions can look like
  dimension: customer__c_name {
    view_label: "customer"
    label: "c_name"
    type: string
    sql: ${TABLE}."customer.c_name" ;;
  }

  # Date dimensions can look like
  dimension_group: orders__o_orderdate {
    view_label: "orders"
    label: "o_orderdate"
    type: time
    sql: ${TABLE}."orders.o_orderdate" ;;
    timeframes: [date, week, month, month_name, month_num, quarter, quarter_of_year, year]
  }

  # Numeric metrics can look like
  measure: customers__count {
    view_label: "customers"
    label: "count"
    type: number
    sql: AGG(${TABLE}."customers.count") ;;
  }
}
```