You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A view is a query which is treated as if it was a table storing the results of the query. The view itself contains no data. The content of a view is generated every time you select from that view. Any changes in the underlying tables are reflected immediately in the view.
3
+
A view is a query which is treated as if it was a table storing the results of the query. The view itself contains no data. The content of a view is generated every time you `SELECT` from it. Thus, any changes in the underlying tables are reflected immediately in the view.
4
4
5
5
Views are often used to:
6
-
- hide query complexity,
7
-
- limit access to underlying data*,
8
-
- provide a backward compatible interface to emulate a table that used to exist, but whose schema has changed.
9
6
10
-
\* The scenario of creating a view to grant other users partial select privileges on a table that has sensitive data is not implemented yet. In {{ ydb-short-name }} view's stored query can only be executed on behalf of the user of the view. A user cannot select from a view that reads from a table that they don't have privileges to select from. See `security_invoker`[option](../../yql/reference/syntax/create_view.md#security_invoker) description on the CREATE VIEW page for details.
7
+
- hide query complexity
8
+
- limit access to underlying data
9
+
- provide a backward-compatible interface to emulate a table that used to exist but whose schema has changed
11
10
12
-
## Creating a view
11
+
{% note warning %}
13
12
14
-
See [CREATE VIEW](../../yql/reference/syntax/create_view.md).
13
+
The scenario of creating a view to grant other users partial `SELECT` privileges on a table that has sensitive data has not been implemented yet. In {{ ydb-short-name }}, the view's stored query can only be executed on behalf of the user querying the view. A user cannot access data from a view that reads from a table that they don't have privileges to `SELECT` from. See the `security_invoker`[option](../../yql/reference/syntax/create_view.md#security_invoker) description on the `CREATE VIEW` page for details.
15
14
16
-
## Altering a view
17
-
18
-
See [ALTER VIEW](../../yql/reference/syntax/alter_view.md).
19
-
20
-
## Dropping a view
21
-
22
-
See [DROP VIEW](../../yql/reference/syntax/drop_view.md).
15
+
{% endnote %}
23
16
24
17
## View invalidation
25
18
26
-
If you drop a table that a view references, the view will become invalid. Queries through it will fail with an error, caused by referencing a table that does not exist. To make this view valid again, you need to provide (create or rename, for example) a selectable object (a table or a view) with the same name (and schema if it was specified in the view's query) that the deleted table had. The dependencies of views on tables (and other views) are not tracked in any way at the moment. Select from a view is executed in the same manner as a select from a subquery would: without any prior checks of validity. You would know that the view's query became invalid only at the moment of its execution. This is going to change in future releases. We are going to start tracking view's dependencies and the default behavior would be to forbid dropping a table if it has a view referencing it.
27
-
28
-
## Query execution context
29
-
30
-
See [notes](../../yql/reference/syntax/create_view.md#notes) on the CREATE VIEW page. Search by the word `context`.
19
+
If you drop a table that a view references, the view will become invalid. Queries against it will fail with an error caused by referencing a table that does not exist. To make the view valid again, you must provide a queriable entity with the same name (by creating or renaming a table or another view). It needs to have a schema compatible with the deleted one. The dependencies of views on tables and other views are not tracked. A `SELECT` from a view is executed like a `SELECT` from a subquery would, without any prior checks of validity. You would know that the view's query became invalid only at the moment of its execution. This approach will change in future releases: {{ ydb-short-name }} will start tracking the view's dependencies, and the default behavior would be to forbid dropping a table if there's a view referencing it.
31
20
32
21
## Performance
33
22
34
-
Queries are executed in 2 steps:
35
-
1. compilation,
36
-
2. execution of the compiled code.
23
+
Queries are executed in two steps:
24
+
1. compilation
25
+
2. execution of the compiled code
37
26
38
-
The resultant compiled code contains no evidence that the query was made using views, because all the references to views should have been replaced during compilation by the queries that they represent. In practice, it means that there must be no difference in the execution time of the compiled code (step №2) for queries made using views vs. queries directly reading from the underlying tables.
27
+
The resulting compiled code contains no evidence that the query was made using views because all the references to views should have been replaced during compilation by the queries that they represent. In practice, there must be no difference in the execution time of the compiled code (step 2) for queries made using views versus queries directly reading from the underlying tables.
39
28
40
-
However, users might notice a little increase in the compilation time of the queries made using views compared to the compilation time of the same queries written directly. It happens due to the fact that a statement reading from a view:
29
+
However, users might notice a little increase in the compilation time of the queries made using views compared to the compilation time of the same queries written directly. It happens because a statement reading from a view:
41
30
```sql
42
31
SELECT*FROM a_view;
43
32
```
@@ -47,23 +36,20 @@ SELECT * FROM (SELECT * FROM underlying_table);
47
36
```
48
37
but with an additional overhead of loading data from the schema object `a_view`.
49
38
50
-
Please note that if you execute the same query over and over again like:
39
+
Please note that if you execute the same query over and over again, like:
51
40
```sql
52
41
-- execute multiple times
53
42
SELECT*FROM hot_view;
54
43
```
55
-
compilation results will be cached on the {{ ydb-short-name }} server and you will not notice any difference in performance of queries using views and direct queries.
44
+
compilation results will be cached on the {{ ydb-short-name }} server side, and you will not notice any difference in the performance of queries using views and direct queries.
56
45
57
46
## View redefinition lag
58
47
59
48
### Query compilation cache
60
-
{{ ydb-short-name }} caches query compilation results on the server side for efficiency. For small queries like:
61
-
```sql
62
-
SELECT1;
63
-
```
64
-
compilation can take up to a hundred times more CPU time than the execution. The cache entry is searched by the text of the query and some additional information such as a user SID.
65
49
66
-
The cache is updated by {{ ydb-short-name }} automatically to stay on track with the changes made to the objects that the query references. However, in the case of views the cache is not updated in the same transaction in which the object's definition changes. It happens with a little delay.
50
+
{{ ydb-short-name }} caches query compilation results on the server side for efficiency. For small queries like `SELECT 1;` compilation can take up to a hundred times more CPU time than the execution. The cache entry is searched by the text of the query and some additional information, such as a user SID.
51
+
52
+
The cache is automatically updated by {{ ydb-short-name }} to stay on track with the changes made to the objects the query references. However, in the case of views, the cache is not updated in the same transaction in which the object's definition changes. It happens with a little delay.
67
53
68
54
### Problem statement
69
55
@@ -81,4 +67,10 @@ DROP VIEW some_view_which_is_going_to_be_redefined;
The text of the Alice's query does not change, which means that the compilation will happen only once and the results are going to be taken from the cache since then. Bob changes the definition of the view and the cache entry for the Alice's query should theoretically be evicted from the cache in the same transaction, in which the view was redefined. However, this is not the case. The Alice's query will be recompiled with a little delay, which means that for a small period of time Alice's query will produce results inconsistent with the updated definition of the view. This is going to be fixed in future releases.
70
+
The text of Alice's query does not change, which means that the compilation will happen only once, and the results are going to be taken from the cache since then. Bob changes the definition of the view, and the cache entry for Alice's query should theoretically be evicted from the cache in the same transaction in which the view was redefined. However, this is not the case. Alice's query will be recompiled with a little delay, which means that for a short period of time, Alice's query will produce results that are inconsistent with the updated definition of the view. This is going to be fixed in future releases.
A view is a logical representation of a table formed by the specified query. The view does not physically store the table, but runs the query to produce the data whenever the view is selected from.
5
+
A view logically represents a table formed by a given query. The view does not physically store the table but executes the query to produce the data whenever the view is accessed.
This clause specifies optional parameters for a view. The following parameters are supported:
27
-
28
-
*`security_invoker` (Bool) {#security_invoker}
29
-
30
-
This option causes the underlying base relations to be checked against the privileges of the user of the view rather than the view owner.
22
+
*`security_invoker` (Bool) {#security_invoker} causes the underlying base relations to be checked against the privileges of the user of the view rather than the view owner.
31
23
32
24
## Notes {#notes}
33
25
34
-
`security_invoker` option must be always set to true, because the default behavior for views is to execute the query on behalf of the view's creator, which is not supported yet.
26
+
The `security_invoker` option must always be set to true because the default behavior for views is to execute the query on behalf of the view's creator, which is not supported yet.
35
27
36
-
The execution context of the view's query is different from the context of the enclosing SELECT from the view statement. It does not "see" previously defined PRAGMAs like TablePathPrefix, named expressions, etc. Most importantly, users must specify the tables (or views) they select from in the view's query by their schema-qualified names. You can see in the [examples](#examples) that the absolute path like `/domain/database/path/to/underlying_table` is used to specify the table, from which a view selects. The particular context of the view's query compilation might change in next releases.
28
+
The execution context of the view's query differs from the context of the enclosing `SELECT`. It does not see previously defined `PRAGMA`s, named expressions, etc. Most importantly, users must specify the tables (or views) they select from in the view's query by their schema-qualified names. You can see in the [examples](#examples) that the absolute path like `/domain/database/path/to/underlying_table` is used to specify the table from which a view reads data. The particular context of the view's query compilation might change in the upcoming releases.
37
29
38
30
If you wish to specify column names that you would like to see in the output of the view, you might do so by modifying the view's query:
39
31
```sql
40
32
CREATEVIEWview_with_a_renamed_column WITH (security_invoker = TRUE) AS
41
-
SELECT
42
-
original_column_name AS custom_column_name
43
-
FROM`/domain/database/path/to/underlying_table`;
33
+
SELECT
34
+
original_column_name AS custom_column_name
35
+
FROM`/domain/database/path/to/underlying_table`;
44
36
```
45
37
46
-
Star (`*`) expansion in the view's query happens each time you read from the view. The list of columns returned by the following statement:
38
+
Asterisk (`*`) expansion in the view's query happens each time you read from the view. The list of columns returned by the following statement:
47
39
```sql
48
40
/*
49
-
CREATE VIEW view_with_a_star WITH (security_invoker = TRUE) AS
50
-
SELECT
51
-
*
52
-
FROM `/domain/database/path/to/underlying_table`;
41
+
CREATE VIEW view_with_an_asterisk WITH (security_invoker = TRUE) AS
42
+
SELECT
43
+
*
44
+
FROM `/domain/database/path/to/underlying_table`;
53
45
*/
54
46
55
-
SELECT*FROMview_with_a_star;
47
+
SELECT*FROMview_with_an_asterisk;
56
48
```
57
49
will change if the list of columns of the `underlying_table` is altered.
58
50
59
51
## Examples {#examples}
60
52
61
-
Create a view that will list only recent series from the series table:
53
+
Create a view that will list only recent series from the `series` table:
62
54
63
55
```sql
64
56
CREATEVIEWrecent_series WITH (security_invoker = TRUE) AS
65
-
SELECT
66
-
*
67
-
FROM`/domain/database/path/to/series`
68
-
WHERE
69
-
release_date >Date("2020-01-01");
57
+
SELECT
58
+
*
59
+
FROM`/domain/database/path/to/series`
60
+
WHERE
61
+
release_date >Date("2020-01-01");
70
62
```
71
63
72
64
Create a view that will list the titles of the first episodes of the recent series:
73
65
74
66
```sql
75
67
CREATEVIEWrecent_series_first_episodes_titles WITH (security_invoker = TRUE) AS
0 commit comments