Views and Aliases
Views are virtual collections defined by SQL queries. A view’s SQL query can reference other views,
collections, aliases, or it may not reference anything. For example,
SELECT 1 does not reference
anything, but is still a valid query for a view.
A few examples of views are:
- A view that selects a specific subset of columns from a collection.
- A view that joins multiple collections into a single virtual table.
A view does not store any data and thus is also known as a non-materialized view. Whenever a view is queried, we execute the query that defines it.
Convenience and Modularity
Views are useful for writing modular SQL. You can replace your CTEs with views and break large, unwieldy queries into manageable chunks.
Scoped Data Access
You can create views that provide a subset of columns or documents from a collection. With custom roles, you can then allow users to access that view without accessing the underlying collection(s).
You can use this mechanism to provide several views on the same underlying collection for different teams or roles without any data duplication.
Like Query Lambdas, you can use views to share particular data views and SQL snippets. Views, unlike Query Lambdas, are queryable themselves and thus are better suited for sharing in many cases.
Once you save your SQL as a view, anyone else with access to that view can use it as a data source for new views and Query Lambdas.
Views can be created and updated from the Query tab of the Rockset Console.
You can find existing views in the Collections tab as well.
You can also manage Views programmatically using the Rockset API.
Note: Updating a view is an asynchronous operation that can take one to two seconds. During this window the view will continue to function with the previous SQL definition. This is usually relevant if you are writing a script that changes a view definition and then immediately queries it.
Like aliases, views should be treated in the same manner as any standard collection in your SQL
queries. Similar to collections, each view exists in a workspace and can be queried by joining its
workspace and name using a dot (.) character in your SQL queries (e.g.,
commons.myView). You can
join them with other collections and views or use them in Query Lambdas.
A collection alias references a collection. By using collection aliases, you can use the alias name in your queries in place of the actual collection name. Additionally, you can switch the alias to a different collection at any time without any downtime for your queries.
Why Collection Aliases?
Collection aliases are useful for versioning your data during bulk refresh of a collection without any unavailability. For instance, you can create a new collection for every bulk refresh, and then switch the alias to reference the latest collection without any downtime for your queries. In case of any issues during bulk refresh, you can always switch the alias back to the previous collection.
Creating Collection Aliases
Once created, you can select the alias to view and manage its details. From there, you can view the status of the referenced collection and Query Lambdas, update the collection referenced by this alias, or delete the alias.
Note that after you update the collection referenced by an alias, there will be a minor delay before the switch is completed. However, there will be no downtime for your queries at any point during the switch, and your queries will automatically begin executing on the new collection once the switch is completed.
Using Collection Aliases
Collection aliases should be treated just like any normal collection in your SQL queries. Like
collections, each collection alias exists in a workspace, and can be queried by joining its
workspace and name using a
. in your SQL queries.
For instance, you might write the following query for a collection alias named
tweets in the
For additional details on how to write and execute queries on collections, seeing the Querying Collections documentation.