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.
Views are useful for writing modular SQL. You can replace your CTEs with views and break large, unwieldy queries into manageable chunks.
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.
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.
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.
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 workspace
SELECT * FROM social.tweets;
For additional details on how to write and execute queries on collections, seeing the Querying Collections documentation.
Updated 1 day ago