SQL Lab

SQL Lab is a modern, feature-rich SQL IDE written in React.


_images/sqllab.png

Feature Overview

  • Connects to just about any database backend
  • A multi-tab environment to work on multiple queries at a time
  • A smooth flow to visualize your query results using Superset’s rich visualization capabilities
  • Browse database metadata: tables, columns, indexes, partitions
  • Support for long-running queries
    • uses the Celery distributed queue to dispatch query handling to workers
    • supports defining a “results backend” to persist query results
  • A search engine to find queries executed in the past
  • Supports templating using the Jinja templating language which allows for using macros in your SQL code

Extra features

  • Hit alt + enter as a keyboard shortcut to run your query

Templating with Jinja

SELECT *
FROM some_table
WHERE partition_key = '{{ presto.latest_partition('some_table') }}'

Templating unleashes the power and capabilities of a programming language within your SQL code.

Templates can also be used to write generic queries that are parameterized so they can be re-used easily.

Available macros

We expose certain modules from Python’s standard library in Superset’s Jinja context:

  • time: time
  • datetime: datetime.datetime
  • uuid: uuid
  • random: random
  • relativedelta: dateutil.relativedelta.relativedelta

Jinja’s builtin filters can be also be applied where needed.

class superset.jinja_context.PrestoTemplateProcessor(database=None, query=None, table=None, **kwargs)[source]

Presto Jinja context

The methods described here are namespaced under presto in the jinja context as in SELECT '{{ presto.some_macro_call() }}'

superset.jinja_context.url_param(param, default=None)[source]

Read a url or post parameter and use it in your SQL Lab query

When in SQL Lab, it’s possible to add arbitrary URL “query string” parameters, and use those in your SQL code. For instance you can alter your url and add ?foo=bar, as in {domain}/superset/sqllab?foo=bar. Then if your query is something like SELECT * FROM foo = ‘{{ url_param(‘foo’) }}’, it will be parsed at runtime and replaced by the value in the URL.

As you create a visualization form this SQL Lab query, you can pass parameters in the explore view as well as from the dashboard, and it should carry through to your queries.

Parameters:
  • param (str) – the parameter to lookup
  • default (str) – the value to return in the absence of the parameter
superset.jinja_context.filter_values(column, default=None)[source]

Gets a values for a particular filter as a list

This is useful if:
  • you want to use a filter box to filter a query where the name of filter box column doesn’t match the one in the select statement
  • you want to have the ability for filter inside the main query for speed purposes

This searches for “filters” and “extra_filters” in form_data for a match

Usage example:
SELECT action, count(*) as times FROM logs WHERE action in ( {{ “’” + “’,’”.join(filter_values(‘action_type’)) + “’” }} ) GROUP BY 1
Parameters:
  • column (str) – column/filter name to lookup
  • default (str) – default value to return if there’s no matching columns
Returns:

returns a list of filter values

Type:

list

Extending macros

As mentioned in the Installation & Configuration documentation, it’s possible for administrators to expose more more macros in their environment using the configuration variable JINJA_CONTEXT_ADDONS. All objects referenced in this dictionary will become available for users to integrate in their queries in SQL Lab.