command changes in batch

docs-2.0/1.introduction/3.nebula-graph-architecture/3.graph-service.md

@@ -20,7 +20,7 @@ After a query is sent to Graph Service, it will be processed by the following fo
 
 After receiving a request, the statements will be parsed by the Parser composed of Flex (lexical analysis tool) and Bison (syntax analysis tool), and its corresponding AST will be generated. Statements will be directly intercepted in this stage because of its invalid syntax.
 
-For example, the structure of the AST of `GO FROM "Tim" OVER like WHERE properties(edge).likeness > 8.0 YIELD dst(edge)` is shown in the following picture.
+For example, the structure of the AST of `GO FROM "Tim" OVER like WHERE like.likeness > 8.0 YIELD like._dst` is shown in the following picture.
 
 ![AST](https://docs-cdn.nebula-graph.com.cn/docs-2.0/1.introduction/2.nebula-graph-architecture/parser-ast-tree.png)
 
@@ -38,7 +38,7 @@ Validator performs a series of validations on the AST. It mainly works on these
 
     Validator will verify whether the cited variable exists or not, or whether the cited property is variable or not.
 
-    For composite statements, like `$var = GO FROM "Tim" OVER like YIELD dst(edge) AS ID; GO FROM $var.ID OVER serve YIELD dst(edge)`, Validator verifies first to see if `var` is defined, and then to check if the `ID` property is attached to the `var` variable.
+    For composite statements, like `$var = GO FROM "Tim" OVER like YIELD like._dst AS ID; GO FROM $var.ID OVER serve YIELD serve._dst`, Validator verifies first to see if `var` is defined, and then to check if the `ID` property is attached to the `var` variable.
 
 - Validating type inference
 
@@ -50,13 +50,13 @@ Validator performs a series of validations on the AST. It mainly works on these
 
     Validator needs to verify all the Schema that involves `*` when verifying the clause if there is a `*` in the statement.
 
-    Take a statement like `GO FROM "Tim" OVER * YIELD dst(edge), properties(edge).likeness, dst(edge)` as an example. When verifying the `OVER` clause, Validator needs to verify all the edge types. If the edge type includes `like` and `serve`, the statement would be `GO FROM "Tim" OVER like,serve YIELD dst(edge), properties(edge).likeness, dst(edge)`.
+    Take a statement like `GO FROM "Tim" OVER * YIELD like._dst, like.likeness, serve._dst` as an example. When verifying the `OVER` clause, Validator needs to verify all the edge types. If the edge type includes `like` and `serve`, the statement would be `GO FROM "Tim" OVER like,serve YIELD like._dst, like.likeness, serve._dst`.
 
 - Validating input and output
 
     Validator will check the consistency of the clauses before and after the `|`.
 
-    In the statement `GO FROM "Tim" OVER like YIELD dst(edge) AS ID | GO FROM $-.ID OVER serve YIELD dst(edge)`, Validator will verify whether `$-.ID` is defined in the clause before the `|`.
+    In the statement `GO FROM "Tim" OVER like YIELD like._dst AS ID | GO FROM $-.ID OVER serve YIELD serve._dst`, Validator will verify whether `$-.ID` is defined in the clause before the `|`.
 
 When the validation succeeds, an execution plan will be generated. Its data structure will be stored in the `src/planner` directory.
 

docs-2.0/14.client/4.nebula-java-client.md

@@ -101,7 +101,7 @@ try {
     ResultSet resp = session.execute(insertEdges);
 
     // query
-    String query = "GO FROM \"Bob\" OVER like " + "YIELD properties($$).name, properties($$).age, properties(edge).likeness";
+    String query = "GO FROM \"Bob\" OVER like " + "YIELD $$.person.name, $$.person.age, like.likeness";
     ResultSet resp = session.execute(query);
     printResult(resp);
 }finally {

docs-2.0/2.quick-start/4.nebula-graph-crud.md

@@ -324,15 +324,14 @@ Users can use the `INSERT` statement to insert vertices or edges based on existi
 * Filter the players that the player with VID `player100` follows whose age is equal to or greater than 35. Rename the corresponding columns in the results with `Teammate` and `Age`.
 
     ```ngql
-    nebula> GO FROM "player100" OVER follow WHERE properties($$).age >= 35 \
-            YIELD properties($$).name AS Teammate, properties($$).age AS Age;
-    +-----------------+-----+
-    | Teammate        | Age |
-    +-----------------+-----+
-    | "Tony Parker"   | 36  |
-    +-----------------+-----+
-    | "Manu Ginobili" | 41  |
-    +-----------------+-----+
+    nebula> GO FROM "player100" OVER follow WHERE $$.player.age >= 35 \
+            YIELD $$.player.name AS Teammate, $$.player.age AS Age;
+    +---------------+-----+
+    | Teammate      | Age |
+    +---------------+-----+
+    | "Tony Parker" | 36  |
+    +---------------+-----+
+    Got 1 rows (time spent 8206/9335 us)
     ```
 
     |Clause/Sign|Description|
@@ -346,18 +345,15 @@ Users can use the `INSERT` statement to insert vertices or edges based on existi
   * With a pipe:
 
     ```ngql
-    nebula> GO FROM "player100" OVER follow YIELD dst(edge) AS id | \
-            GO FROM $-.id OVER serve YIELD properties($$).name AS Team, \
-            properties($^).name AS Player;
-    +-----------+-----------------+
-    | Team      | Player          |
-    +-----------+-----------------+
-    | "Spurs"   | "Tony Parker"   |
-    +-----------+-----------------+
-    | "Hornets" | "Tony Parker"   |
-    +-----------+-----------------+
-    | "Spurs"   | "Manu Ginobili" |
-    +-----------+-----------------+    
+    nebula> GO FROM "player100" OVER follow YIELD follow._dst AS id | \
+            GO FROM $-.id OVER serve YIELD $$.team.name AS Team, \
+            $^.player.name AS Player;
+    +-----------+---------------+
+    | Team      | Player        |
+    +-----------+---------------+
+    | "Nuggets" | "Tony Parker" |
+    +-----------+---------------+
+    Got 1 rows (time spent 5055/8203 us)
     ```
 
     |Clause/Sign|Description|
@@ -373,18 +369,15 @@ Users can use the `INSERT` statement to insert vertices or edges based on existi
         Once a composite statement is submitted to the server as a whole, the life cycle of the temporary variables in the statement ends.
 
     ```ngql
-    nebula> $var = GO FROM "player100" OVER follow YIELD dst(edge) AS id; \
-            GO FROM $var.id OVER serve YIELD properties($$).name AS Team, \
-            properties($^).name AS Player;
-    +-----------+-----------------+
-    | Team      | Player          |
-    +-----------+-----------------+
-    | "Spurs"   | "Tony Parker"   |
-    +-----------+-----------------+
-    | "Hornets" | "Tony Parker"   |
-    +-----------+-----------------+
-    | "Spurs"   | "Manu Ginobili" |
-    +-----------+-----------------+
+    nebula> $var = GO FROM "player100" OVER follow YIELD follow._dst AS id; \
+            GO FROM $var.id OVER serve YIELD $$.team.name AS Team, \
+            $^.player.name AS Player;
+    +---------+-------------+
+    | Team    | Player      |
+    +---------+-------------+
+    | Nuggets | Tony Parker |
+    +---------+-------------+
+    Got 1 rows (time spent 3103/3711 us)
     ```
 
 ### Example of `FETCH` statement
@@ -398,6 +391,7 @@ nebula> FETCH PROP ON player "player100";
 +----------------------------------------------------+
 | ("player100" :player{age: 42, name: "Tim Duncan"}) |
 +----------------------------------------------------+
+Got 1 rows (time spent 2006/2406 us)
 ```
 
 !!! Note

docs-2.0/3.ngql-guide/1.nGQL-overview/1.overview.md

@@ -153,8 +153,8 @@ Feature:  Comparison of where clause
       When profiling query:
         """
         GO FROM "player100" OVER follow 
-        WHERE properties(edge).degree IN [v IN [95,99] WHERE v > 0] 
-        YIELD dst(edge), properties(edge).degree
+        WHERE follow.degree IN [v IN [95,99] WHERE v > 0] 
+        YIELD follow._dst, follow.degree
         """
       Then the result should be, in any order:
         | follow._dst | follow.degree |
@@ -163,7 +163,7 @@ Feature:  Comparison of where clause
       And the execution plan should be:
         | id | name         | dependencies | operator info                                               |
         | 0  | Project      | 1            |                                                             |
-        | 1  | GetNeighbors | 2            | {"filter": "(properties(edge).degree IN [v IN [95,99] WHERE (v>0)])"} |
+        | 1  | GetNeighbors | 2            | {"filter": "(follow.degree IN [v IN [95,99] WHERE (v>0)])"} |
         | 2  | Start        |              |                                                             |
 ```
 

docs-2.0/3.ngql-guide/1.nGQL-overview/ngql-style-guide.md

@@ -13,35 +13,35 @@ nGQL does not have strict formatting requirements, but creating nGQL statements
   Not recommended:
 
   ```ngql
-  GO FROM "player100" OVER follow REVERSELY YIELD src(edge) AS id;
+  GO FROM "player100" OVER follow REVERSELY YIELD follow._dst AS id;
   ```
 
   Recommended:
 
   ```ngql
   GO FROM "player100" \
   OVER follow REVERSELY \
-  YIELD src(edge) AS id;
+  YIELD follow._dst AS id;
   ```
 
 2. Start a new line to write different statements in a composite statement.
 
   Not recommended:
 
   ```ngql
-  GO FROM "player100" OVER follow REVERSELY YIELD src(edge) AS id | GO FROM $-.id \
-  OVER serve WHERE properties($^).age > 20 YIELD properties($^).name AS FriendOf, properties($$).name AS Team;
+  GO FROM "player100" OVER follow REVERSELY YIELD follow._dst AS id | GO FROM $-.id \
+  OVER serve WHERE $^.player.age > 20 YIELD $^.player.name AS FriendOf, $$.team.name AS Team;
   ```
 
   Recommended:
 
   ```ngql
   GO FROM "player100" \
   OVER follow REVERSELY \
-  YIELD src(edge) AS id | \
+  YIELD follow._dst AS id | \
   GO FROM $-.id OVER serve \
-  WHERE properties($^).age > 20 \
-  YIELD properties($^).name AS FriendOf, properties($$).name AS Team;
+  WHERE $^.player.age > 20 \
+  YIELD $^.player.name AS FriendOf, $$.team.name AS Team;
   ```
 
 3. If the clause exceeds 80 characters, start a new line at the appropriate place.
@@ -218,21 +218,21 @@ The strings should be surrounded by double quotes.
   ```ngql
   GO FROM "player100" \
   OVER follow \
-  YIELD dst(edge) AS id; | \
+  YIELD follow._dst AS id; | \
   GO FROM $-.id \
   OVER serve \
-  YIELD properties($$).name AS Team, properties($^).name AS Player;
+  YIELD $$.team.name AS Team, $^.player.name AS Player;
   ```
 
   Supported:
 
   ```ngql
   GO FROM "player100" \
   OVER follow \
-  YIELD dst(edge) AS id | \
+  YIELD follow._dst AS id | \
   GO FROM $-.id \
   OVER serve \
-  YIELD properties($$).name AS Team, properties($^).name AS Player;
+  YIELD $$.team.name AS Team, $^.player.name AS Player;
   ```
 
 3. In a composite statement that contains user-defined variables, use an English semicolon to end the statements that define the variables. If you do not follow the rules to add a semicolon or use a pipe to end the composite statement, the execution will fail.

docs-2.0/3.ngql-guide/12.vertex-statements/4.delete-vertex.md

@@ -27,7 +27,7 @@ nebula> DELETE VERTEX "team1";
 This query shows that you can use `DELETE VERTEX` together with pipe to delete vertices.
 
 ```ngql
-nebula> GO FROM "player100" OVER serve WHERE properties(edge).start_year == "2021" YIELD dst(edge) AS id | DELETE VERTEX $-.id;
+nebula> GO FROM "player100" OVER serve WHERE serve.start_year == "2021" YIELD serve._dst AS id | DELETE VERTEX $-.id;
 ```
 
 ## Delete the process and the related edges

docs-2.0/3.ngql-guide/13.edge-statements/2.update-edge.md

@@ -31,7 +31,7 @@ The following example checks the properties of the edge with the GO statement.
 ```ngql
 nebula> GO FROM "player100" \
         OVER serve \
-        YIELD properties(edge).start_year, properties(edge).end_year;
+        YIELD serve.start_year, serve.end_year;
 +------------------+----------------+
 | serve.start_year | serve.end_year |
 +------------------+----------------+

docs-2.0/3.ngql-guide/13.edge-statements/4.delete-edge.md

@@ -24,7 +24,7 @@ The following example shows that you can use `DELETE EDGE` together with pipe op
 
 ```ngql
 nebula> GO FROM "player100" OVER follow \
-        WHERE dst(edge) == "team204" \
-        YIELD src(edge) AS src, dst(edge) AS dst, rank(edge) AS rank \
+        WHERE follow._dst == "team204" \
+        YIELD follow._src AS src, follow._dst AS dst, follow._rank AS rank \
         | DELETE EDGE follow $-.src->$-.dst @ $-.rank;
 ```

docs-2.0/3.ngql-guide/3.data-types/6.list.md

@@ -180,8 +180,8 @@ nebula> RETURN size([1,2,3]);
 +---------------+
 
 # The following query calculates the elements in the list [92,90] and runs a conditional judgment in a where clause.
-nebula> GO FROM "player100" OVER follow WHERE properties(edge).degree NOT IN [x IN [92, 90] | x + $$.player.age] \
-        YIELD dst(edge) AS id, properties(edge).degree AS degree;
+nebula> GO FROM "player100" OVER follow WHERE follow.degree NOT IN [x IN [92, 90] | x + $$.player.age] \
+        YIELD follow._dst AS id, follow.degree AS degree;
 +-------------+--------+
 | id          | degree |
 +-------------+--------+

docs-2.0/3.ngql-guide/4.variable-and-composite-queries/1.composite-queries.md

@@ -58,16 +58,12 @@ For example, a query is composed of three sub-queries: `A B C`, `A | B | C` or `
 
     ```ngql
     # Connect multiple queries with pipes.
-    nebula> GO FROM "player100" OVER follow YIELD dst(edge) AS id | \
-            GO FROM $-.id OVER serve YIELD properties($$).name AS Team, \
-            properties($^).name AS Player;
-    +-----------+-----------------+
-    | Team      | Player          |
-    +-----------+-----------------+
-    | "Spurs"   | "Tony Parker"   |
-    +-----------+-----------------+
-    | "Hornets" | "Tony Parker"   |
-    +-----------+-----------------+
-    | "Spurs"   | "Manu Ginobili" |
-    +-----------+-----------------+
+    nebula> GO FROM "player100" OVER follow YIELD follow._dst AS id | \
+            GO FROM $-.id OVER serve YIELD $$.team.name AS Team, \
+            $^.player.name AS Player;
+    +---------+-------------+
+    | Team    | Player      |
+    +---------+-------------+
+    | Nuggets | Tony Parker |
+    +---------+-------------+
     ```

docs-2.0/3.ngql-guide/4.variable-and-composite-queries/2.user-defined-variables.md

@@ -32,16 +32,12 @@ You can use user-defined variables in composite queries. Details about composite
 ## Example
 
 ```ngql
-nebula> $var = GO FROM "player100" OVER follow YIELD dst(edge) AS id; \
-        GO FROM $var.id OVER serve YIELD properties($$).name AS Team, \
-        properties($^).name AS Player;
-+-----------+-----------------+
-| Team      | Player          |
-+-----------+-----------------+
-| "Spurs"   | "Tony Parker"   |
-+-----------+-----------------+
-| "Hornets" | "Tony Parker"   |
-+-----------+-----------------+
-| "Spurs"   | "Manu Ginobili" |
-+-----------+-----------------+
+nebula> $var = GO FROM "player100" OVER follow YIELD follow._dst AS id; \
+        GO FROM $var.id OVER serve YIELD $$.team.name AS Team, \
+        $^.player.name AS Player;
++---------+-------------+
+| Team    | Player      |
++---------+-------------+
+| Nuggets | Tony Parker |
++---------+-------------+
 ```

docs-2.0/3.ngql-guide/4.variable-and-composite-queries/3.property-reference.md

@@ -61,7 +61,7 @@ Apart from the user-defined edge property, there are four built-in properties in
 The following query returns the `name` property of the `player` tag on the source vertex and the `age` property of the `player` tag on the destination vertex.
 
 ```ngql
-nebula> GO FROM "player100" OVER follow YIELD properties($^).name AS startName, properties($$).age AS endAge;
+nebula> GO FROM "player100" OVER follow YIELD $^.player.name AS startName, $$.player.age AS endAge;
 +--------------+--------+
 | startName    | endAge |
 +--------------+--------+
@@ -74,7 +74,7 @@ nebula> GO FROM "player100" OVER follow YIELD properties($^).name AS startName,
 The following query returns the `degree` property of the edge type `follow`.
 
 ```ngql
-nebula> GO FROM "player100" OVER follow YIELD properties(edge).degree;
+nebula> GO FROM "player100" OVER follow YIELD follow.degree;
 +---------------+
 | follow.degree |
 +---------------+
@@ -87,12 +87,12 @@ nebula> GO FROM "player100" OVER follow YIELD properties(edge).degree;
 The following query returns the source vertex, the destination vertex, the edge type, and the edge rank value of the edge type `follow`.
 
 ```ngql
-nebula> GO FROM "player100" OVER follow YIELD src(edge), dst(edge), type(edge), rank(edge);
-+-------------+-------------+------------+------------+
-| src(EDGE)   | dst(EDGE)   | type(EDGE) | rank(EDGE) |
-+-------------+-------------+------------+------------+
-| "player100" | "player101" | "follow"   | 0          |
-+-------------+-------------+------------+------------+
-| "player100" | "player125" | "follow"   | 0          |
-+-------------+-------------+------------+------------+
+nebula> GO FROM "player100" OVER follow YIELD follow._src, follow._dst, follow._type, follow._rank;
++-------------+-------------+--------------+--------------+
+| follow._src | follow._dst | follow._type | follow._rank |
++-------------+-------------+--------------+--------------+
+| "player100" | "player101" | 136          | 0            |
++-------------+-------------+--------------+--------------+
+| "player100" | "player102" | 136          | 0            |
++-------------+-------------+--------------+--------------+
 ```

docs-2.0/3.ngql-guide/5.operators/1.comparison.md

@@ -190,15 +190,13 @@ nebula> RETURN "a" IS NOT EMPTY;
 | true             |
 +------------------+
 
-nebula> GO FROM "player100" OVER * WHERE properties($$).name IS NOT EMPTY YIELD dst(edge);
+nebula> GO FROM "player100" OVER * WHERE $$.player.name IS NOT EMPTY YIELD follow._dst;
 +-------------+
-| dst(EDGE)   |
+| follow._dst |
 +-------------+
-| "team204"   |
+| "player125" |
 +-------------+
 | "player101" |
 +-------------+
-| "player125" |
-+-------------+
 
 ```

docs-2.0/3.ngql-guide/5.operators/4.pipe.md

@@ -18,15 +18,14 @@ One major difference between nGQL and SQL is how sub-queries are composed.
 
 ```ngql
 nebula> GO FROM "player100" OVER follow \
-        YIELD dst(edge) AS dstid, properties($$).name AS Name | \
+        YIELD follow._dst AS dstid, $$.player.name AS Name | \
         GO FROM $-.dstid OVER follow;
 
 +-------------+
 | follow._dst |
 +-------------+
 | "player101" |
 +-------------+
-|...          |
 ```
 
 If there is no `YIELD` clause to define the output, the destination vertex ID is returned by default. If a YIELD clause is applied, the output is defined by the YIELD clause.