en rewrite

Author: jepett0

ydb/docs/en/core/concepts/datamodel/view.md

@@ -1,13 +1,13 @@
 # View
 
-A view is basically a query that is stored in a database which enables you to treat the results of the query as a table. The view itself contains no data. The results of a view are generated every time you select from that view. Any changes in the underlying tables are reflected immediately in the view.
+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.
 
 Views are often used to:
 - hide query complexity,
-- limit access to underlaying data*,
+- limit access to underlying data*,
 - provide a backward compatible interface to emulate a table that used to exist, but whose schema has changed.
 
-\* 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 select privileges from. See `security_invoker` option description on the [CREATE VIEW](../../yql/reference/syntax/create_view.md) page for details.
+\* 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.
 
 ## Creating a view
 
@@ -23,11 +23,21 @@ See [DROP VIEW](../../yql/reference/syntax/drop_view.md).
 
 ## View invalidation
 
-If you drop a table that the view references, the view will become invalid. The queries through it will fail with an error of referencing a table that does not exist. The dependencies of views on the 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 will know that the view's query became invalid only at the moment of its execution. This is going to change in the future releases. We are going to start tracking view's dependencies and the default behavior for dropping a table would be to forbid it if any view is referencing the table.
+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 a 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.
+
+## Query execution context
+
+See [notes](../../yql/reference/syntax/create_view.md#notes) on the CREATE VIEW page. Search by the word `context`.
 
 ## Performance
 
-Users might notice a little increase in the compilation time of the queries made using views compared to the compilation time of the same query, where views are substituted by their queries. It happens due to the fact that a statement reading from a view:
+Queries are executed in 2 steps:
+1. compilation,
+2. execution of the compiled code.
+
+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. It 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.
+
+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:
 ```sql
 SELECT * FROM a_view;
 ```
@@ -44,24 +54,22 @@ SELECT * FROM hot_view;
 ```
 compilation results will be cached on the {{ ydb-short-name }} server and you will not notice any decrease of performance of queries using views.
 
-Execution time of the resulting compiled code for queries using views should always be exactly the same as for the queries directly reading data from the underlying tables.
-
 ## View redefinition lag
 
 ### Query compilation cache
 {{ ydb-short-name }} caches query compilation results on the server side for efficiency. For small queries like:
 ```sql
 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 parameters such as a user SID.
+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 info such as a user SID.
 
-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 has changed. It happens with a little delay.
+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.
 
 ### Problem statement
 
-Imagine the following sitiuation:
+Imagine the following situation.
 
-Alice continiously executes the following query:
+Alice continuously executes the following query:
 ```sql
 -- Alice's session
 SELECT * FROM some_view_which_is_going_to_be_redefined;
@@ -73,4 +81,4 @@ DROP VIEW some_view_which_is_going_to_be_redefined;
 CREATE 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 the future releases.
+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.

ydb/docs/en/core/yql/reference/yql-core/syntax/create_view.md

@@ -2,7 +2,7 @@
 
 CREATE VIEW defines a view of a query.
 
-A view is a logical representation of a table formed by the query, specified at the moment of the view's creation. The view does not physically store the table, but runs the query to produce the data whenever the view is selected from.
+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.
 
 ## Syntax
 
@@ -25,11 +25,11 @@ The SELECT query, which will be used to produce the logical table the view repre
 
 This clause specifies optional parameters for a view. The following parameters are supported:
 
-* `security_invoker` (Bool)
+* `security_invoker` (Bool) {#security_invoker}
 
 This option causes the underlying base relations to be checked against the privileges of the user of the view rather than the view owner.
 
-## Notes
+## Notes {#notes}
 
 `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.