From deb377ca993fcb6be2ba3a3c85473b8d9fb6b278 Mon Sep 17 00:00:00 2001 From: Daniil Timizhev Date: Thu, 17 Jul 2025 20:51:36 +0300 Subject: [PATCH 01/17] Add NoTx mode --- ydb/docs/en/core/concepts/_includes/transactions.md | 9 +++++++++ ydb/docs/en/core/yql/reference/syntax/batch-delete.md | 2 +- ydb/docs/en/core/yql/reference/syntax/batch-update.md | 2 +- ydb/docs/ru/core/concepts/_includes/transactions.md | 9 +++++++++ ydb/docs/ru/core/yql/reference/syntax/batch-delete.md | 2 +- ydb/docs/ru/core/yql/reference/syntax/batch-update.md | 2 +- 6 files changed, 22 insertions(+), 4 deletions(-) diff --git a/ydb/docs/en/core/concepts/_includes/transactions.md b/ydb/docs/en/core/concepts/_includes/transactions.md index 084cc3d919ae..4987fdfebec6 100644 --- a/ydb/docs/en/core/concepts/_includes/transactions.md +++ b/ydb/docs/en/core/concepts/_includes/transactions.md @@ -20,6 +20,15 @@ If consistency or freshness requirement for data read by a transaction can be re * *Stale Read-Only*: Read operations within a transaction may return results that are slightly out-of-date (lagging by fractions of a second). Each individual read returns consistent data, but no consistency between different reads is guaranteed. * *Snapshot Read-Only*: All the read operations within a transaction access the database snapshot. All the data reads are consistent. The snapshot is taken when the transaction begins, meaning the transaction sees all changes committed before it began. +### Implicit Transaction Control {#implicit} + +In addition to explicit transaction management, {{ ydb-short-name }} supports *Implicit Transaction Control* mode (no transaction), where the server automatically handles transaction lifecycle without requiring explicit transaction creation. This mode provides universal support for all query types with the following characteristics: + +* DDL queries — executed outside of a transaction context. Multistatement operations are supported only when all statements are DDL. Changes are not rolled back if errors occur. +* DML queries — automatically wrapped in a transaction in *Serializable* mode. Multistatement operations are supported only when all statements are DML. Changes are committed on success or rolled back on error. +* Other query types: + * `BATCH UPDATE`, `BATCH DELETE FROM` — executed outside of a transaction context. Multistatement operations are not supported. Changes are not rolled back if errors occur. + The transaction execution mode is specified in its settings when creating the transaction. See the examples for the {{ ydb-short-name }} SDK in the [{#T}](../../recipes/ydb-sdk/tx-control.md). ## YQL Language {#language-yql} diff --git a/ydb/docs/en/core/yql/reference/syntax/batch-delete.md b/ydb/docs/en/core/yql/reference/syntax/batch-delete.md index 974f70c9d060..c01f9ee8a7e6 100644 --- a/ydb/docs/en/core/yql/reference/syntax/batch-delete.md +++ b/ydb/docs/en/core/yql/reference/syntax/batch-delete.md @@ -13,7 +13,7 @@ This query, like the standard `DELETE FROM`, executes synchronously and returns The semantics are inherited from the standard `DELETE FROM` with the following restrictions: * Supported only for [row-oriented tables](../../../concepts/glossary.md#row-oriented-table). -* Supported only for queries with implicit transaction control (`NoTx` mode or `EmptyTxControl` in SDK). +* Supported only for queries with [implicit transaction control](../../../concepts/transactions.md#implicit). * The use of subqueries and multiple statements in a single query is prohibited. * The `RETURNING` clause is unavailable. diff --git a/ydb/docs/en/core/yql/reference/syntax/batch-update.md b/ydb/docs/en/core/yql/reference/syntax/batch-update.md index 0b60e0baba7b..4e130feb481d 100644 --- a/ydb/docs/en/core/yql/reference/syntax/batch-update.md +++ b/ydb/docs/en/core/yql/reference/syntax/batch-update.md @@ -13,7 +13,7 @@ This query, like the standard `UPDATE`, executes synchronously and returns a sta The semantics are inherited from the standard `UPDATE` with the following restrictions: * Supported only for [row-oriented tables](../../../concepts/glossary.md#row-oriented-table). -* Supported only for queries with implicit transaction control (`NoTx` mode or `EmptyTxControl` in SDK). +* Supported only for queries with [implicit transaction control](../../../concepts/transactions.md#implicit). * Only idempotent updates are supported: expressions following `SET` should not depend on the current values of the columns being modified. * The use of subqueries and multiple statements in a single query is prohibited. * The `RETURNING` clause is unavailable. diff --git a/ydb/docs/ru/core/concepts/_includes/transactions.md b/ydb/docs/ru/core/concepts/_includes/transactions.md index 6209ab1f0b7a..cabe00eee9f8 100644 --- a/ydb/docs/ru/core/concepts/_includes/transactions.md +++ b/ydb/docs/ru/core/concepts/_includes/transactions.md @@ -18,6 +18,15 @@ * *Stale Read-Only* — чтения данных в транзакции возвращают результаты с возможным отставанием от актуальных (доли секунды). Данные в каждом отдельно взятом чтении консистентны, между разными чтениями консистентность данных не гарантируется. * *Snapshot Read-Only* — все чтения транзакции производятся из снапшота базы данных, при этом все чтения данных консистентны. Взятие снапшота происходит в момент старта транзакции, т.е. транзакция видит все изменения, закоммиченные до момента своего начала. +### Неявный контроль транзакции {#implicit} + +В дополнение к явному управлению транзакциями, {{ ydb-short-name }} поддерживает режим *Implicit Transaction Control* (неявный контроль транзакции, no transaction), при котором сервер автоматически обрабатывает жизненный цикл транзакции, не требуя явного её создания. Данный режим обеспечивает универсальную поддержку всех типов запросов со следующими характеристиками: + +* DDL запросы — выполняются вне транзакции. Запросы с несколькими операторами поддерживаются только в том случае, если все операторы являются DDL. Изменения не откатываются в случае возникновения ошибок. +* DML запросы — автоматически оборачиваются в транзакцию режима *Serializable*. Запросы с несколькими операторами поддерживаются только в том случае, если все операторы являются DML. Изменения коммитятся (фиксируются) в случае успеха или откатываются в случае ошибки. +* Другие виды запросов: + * `BATCH UPDATE`, `BATCH DELETE FROM` — выполняются вне транзакции. Запросы с несколькими операторами не поддерживаются. Изменения не откатываются в случае возникновения ошибок. + Режим выполнения транзакции задается в настройках транзакции при ее создании. Примеры для {{ ydb-short-name }} SDK смотрите в статье [{#T}](../../recipes/ydb-sdk/tx-control.md). ## Язык YQL {#language-yql} diff --git a/ydb/docs/ru/core/yql/reference/syntax/batch-delete.md b/ydb/docs/ru/core/yql/reference/syntax/batch-delete.md index b91046ceecc9..78924e5c694f 100644 --- a/ydb/docs/ru/core/yql/reference/syntax/batch-delete.md +++ b/ydb/docs/ru/core/yql/reference/syntax/batch-delete.md @@ -13,7 +13,7 @@ Семантика наследуется от стандартного `DELETE FROM` с ограничениями: * Поддерживается только для [строковых таблиц](../../../concepts/glossary.md#row-oriented-table). -* Поддерживается только для неявного контроля транзакции (режим `NoTx` или `EmptyTxControl` в SDK). +* Поддерживается только для режима [неявного контроля транзакций](../../../concepts/transactions.md#implicit). * Запрещено использование подзапросов и нескольких выражений в одном запросе. * Недоступно ключевое слово `RETURNING`. diff --git a/ydb/docs/ru/core/yql/reference/syntax/batch-update.md b/ydb/docs/ru/core/yql/reference/syntax/batch-update.md index 9e7ba7e91827..cf63547703d1 100644 --- a/ydb/docs/ru/core/yql/reference/syntax/batch-update.md +++ b/ydb/docs/ru/core/yql/reference/syntax/batch-update.md @@ -14,7 +14,7 @@ Семантика наследуется от стандартного `UPDATE` с ограничениями: * Поддерживается только для [строковых таблиц](../../../concepts/glossary.md#row-oriented-table). -* Поддерживается только для неявного контроля транзакции (режим `NoTx` или `EmptyTxControl` в SDK). +* Поддерживается только для режима [неявного контроля транзакций](../../../concepts/transactions.md#implicit). * Поддерживаются только идемпотентные обновления: выражения после `SET` не должны зависеть от текущих значений изменяемых колонок. * Запрещено использование подзапросов и нескольких выражений в одном запросе. * Недоступно ключевое слово `RETURNING`. From 143f883899e5a3a97ed7e3d664f47c22f8811c02 Mon Sep 17 00:00:00 2001 From: Daniil Timizhev Date: Wed, 23 Jul 2025 15:49:53 +0300 Subject: [PATCH 02/17] Fixes after review --- .../core/concepts/_includes/transactions.md | 32 +++++++++++++++---- .../core/concepts/_includes/transactions.md | 30 +++++++++++++---- 2 files changed, 50 insertions(+), 12 deletions(-) diff --git a/ydb/docs/en/core/concepts/_includes/transactions.md b/ydb/docs/en/core/concepts/_includes/transactions.md index 4987fdfebec6..e8eae2d6c62c 100644 --- a/ydb/docs/en/core/concepts/_includes/transactions.md +++ b/ydb/docs/en/core/concepts/_includes/transactions.md @@ -20,17 +20,37 @@ If consistency or freshness requirement for data read by a transaction can be re * *Stale Read-Only*: Read operations within a transaction may return results that are slightly out-of-date (lagging by fractions of a second). Each individual read returns consistent data, but no consistency between different reads is guaranteed. * *Snapshot Read-Only*: All the read operations within a transaction access the database snapshot. All the data reads are consistent. The snapshot is taken when the transaction begins, meaning the transaction sees all changes committed before it began. -### Implicit Transaction Control {#implicit} +### Implicit Transactions in {{ ydb-short-name }} {#implicit} -In addition to explicit transaction management, {{ ydb-short-name }} supports *Implicit Transaction Control* mode (no transaction), where the server automatically handles transaction lifecycle without requiring explicit transaction creation. This mode provides universal support for all query types with the following characteristics: +When a transaction is not explicitly defined for a query, {{ ydb-short-name }} automatically manages transactional behavior. This is referred to as an implicit transaction. Unlike explicit transactions, where applications initiate and commit transactions directly, implicit transactions are internally handled by the {{ ydb-short-name }} server when no explicit transaction mode is specified. -* DDL queries — executed outside of a transaction context. Multistatement operations are supported only when all statements are DDL. Changes are not rolled back if errors occur. -* DML queries — automatically wrapped in a transaction in *Serializable* mode. Multistatement operations are supported only when all statements are DML. Changes are committed on success or rolled back on error. -* Other query types: - * `BATCH UPDATE`, `BATCH DELETE FROM` — executed outside of a transaction context. Multistatement operations are not supported. Changes are not rolled back if errors occur. +**Behavior and Guarantees** + +The guarantees provided by implicit transactions are generally weaker than those offered by explicit transactions. In particular, some types of operations executed via implicit transactions cannot be rolled back if an error occurs. The behavior varies depending on the type of statement: + +- **Data Definition Language (DDL) Statements** + DDL queries (such as `CREATE TABLE`, `DROP TABLE`, etc.) are always executed outside of any transaction context. Multistatement queries are supported only if all statements are DDL. If an error occurs, changes made by previous statements within the batch are not rolled back. + +- **Data Manipulation Language (DML) Statements** + DML queries (such as `INSERT`, `UPDATE`, `DELETE`, etc.) are automatically executed inside a transaction with Snapshot (for read-only queries) or Serializable (for read-write queries) isolation, created and managed by the server. Multistatement queries are supported if all statements are DML. On successful execution, changes are committed; if an error occurs, all changes are rolled back. + +- **BATCH UPDATE / BATCH DELETE FROM Statements** + Batch modification statements are executed outside of a transactional context. Multistatement queries are not supported. As with DDL, changes are not rolled back if an error occurs during execution. + +**Summary Table** + +| Statement Type | Implicit Transaction Handling | Multistatement Support | Rollback on Error | +|----------------|-----------------------------------------------|------------------------|-----------------------| +| DDL | Outside transaction context | Yes (DDL-only) | No | +| DML | Auto transaction (Serializable/Snapshot) | Yes (DML-only) | Yes | +| BATCH UPDATE / BATCH DELETE FROM | Outside transaction context | No | No | + +When using implicit transactions, be aware of these limitations and reduced guarantees compared to explicit transactions. For advanced transaction control, error handling, or atomicity across diverse statements, it is strongly recommended to use explicit transactions. The transaction execution mode is specified in its settings when creating the transaction. See the examples for the {{ ydb-short-name }} SDK in the [{#T}](../../recipes/ydb-sdk/tx-control.md). +--- + ## YQL Language {#language-yql} Statements implemented in YQL can be divided into two classes: [Data Definition Language (DDL)](https://en.wikipedia.org/wiki/Data_definition_language) and [Data Manipulation Language (DML)](https://en.wikipedia.org/wiki/Data_manipulation_language). diff --git a/ydb/docs/ru/core/concepts/_includes/transactions.md b/ydb/docs/ru/core/concepts/_includes/transactions.md index cabe00eee9f8..66fecdb2c0dd 100644 --- a/ydb/docs/ru/core/concepts/_includes/transactions.md +++ b/ydb/docs/ru/core/concepts/_includes/transactions.md @@ -18,17 +18,35 @@ * *Stale Read-Only* — чтения данных в транзакции возвращают результаты с возможным отставанием от актуальных (доли секунды). Данные в каждом отдельно взятом чтении консистентны, между разными чтениями консистентность данных не гарантируется. * *Snapshot Read-Only* — все чтения транзакции производятся из снапшота базы данных, при этом все чтения данных консистентны. Взятие снапшота происходит в момент старта транзакции, т.е. транзакция видит все изменения, закоммиченные до момента своего начала. -### Неявный контроль транзакции {#implicit} +### Неявные транзакции в {{ ydb-short-name }} {#implicit} -В дополнение к явному управлению транзакциями, {{ ydb-short-name }} поддерживает режим *Implicit Transaction Control* (неявный контроль транзакции, no transaction), при котором сервер автоматически обрабатывает жизненный цикл транзакции, не требуя явного её создания. Данный режим обеспечивает универсальную поддержку всех типов запросов со следующими характеристиками: +Если для запроса транзакция не определена явно, {{ ydb-short-name }} автоматически управляет транзакционным поведением. Такой подход называется неявной транзакцией. В отличие от явных транзакций, когда приложение напрямую инициирует и подтверждает транзакции, неявные транзакции обрабатываются внутренне сервером {{ ydb-short-name }}, если явный режим транзакции не задан. -* DDL запросы — выполняются вне транзакции. Запросы с несколькими операторами поддерживаются только в том случае, если все операторы являются DDL. Изменения не откатываются в случае возникновения ошибок. -* DML запросы — автоматически оборачиваются в транзакцию режима *Serializable*. Запросы с несколькими операторами поддерживаются только в том случае, если все операторы являются DML. Изменения коммитятся (фиксируются) в случае успеха или откатываются в случае ошибки. -* Другие виды запросов: - * `BATCH UPDATE`, `BATCH DELETE FROM` — выполняются вне транзакции. Запросы с несколькими операторами не поддерживаются. Изменения не откатываются в случае возникновения ошибок. +**Поведение и гарантии** + +Гарантии, которые предоставляют неявные транзакции, как правило, слабее, чем у явных. В частности, некоторые типы операций, выполненные через неявные транзакции, невозможно откатить в случае ошибки. Поведение зависит от типа оператора: + +- **Data Definition Language (DDL) операторы** + DDL-запросы (такие как `CREATE TABLE`, `DROP TABLE` и т.д.) всегда выполняются вне транзакционного контекста. Запросы, состоящие из нескольких операторов, поддерживаются только в том случае, если все они являются DDL. При возникновении ошибки изменения, внесенные предыдущими операторами в пакете, не отменяются (не откатываются). + +- **Data Manipulation Language (DML) инструкции** + DML-запросы (такие как `INSERT`, `UPDATE`, `DELETE` и т.д.) автоматически выполняются внутри транзакции с уровнем изоляции Snapshot (для запросов только на чтение) или Serializable (для запросов на чтение-запись). Такая транзакция создается и управляется сервером. Поддерживаются запросы из нескольких инструкций, если все они являются DML. При успешном выполнении изменения коммитятся (фиксируются); в случае ошибки все изменения откатываются. + +- **Инструкции BATCH UPDATE / BATCH DELETE FROM** + Операторы пакетного изменения выполняются вне транзакционного контекста. Запросы из нескольких операторов не поддерживаются. Как и в случае с DDL, при возникновении ошибки во время выполнения изменения не откатываются. + +**Сводная таблица** + +| Тип оператора | Обработка неявной транзакции | Поддержка нескольких операторов | Откат при ошибке | +|----------------|---------------------------------------------------|---------------------------------|-----------------------| +| DDL | Вне транзакционного контекста | Да (только DDL) | Нет | +| DML | Автоматическая транзакция (Serializable/Snapshot) | Да (только DML) | Да | +| `BATCH UPDATE` / `BATCH DELETE FROM` | Вне транзакционного контекста | Нет | Нет | Режим выполнения транзакции задается в настройках транзакции при ее создании. Примеры для {{ ydb-short-name }} SDK смотрите в статье [{#T}](../../recipes/ydb-sdk/tx-control.md). +--- + ## Язык YQL {#language-yql} Реализованные конструкции YQL можно разделить на два класса: [data definition language (DDL)](https://en.wikipedia.org/wiki/Data_definition_language) и [data manipulation language (DML)](https://en.wikipedia.org/wiki/Data_manipulation_language). From d8cd52d1526252ae80c1e890a0449b05052bb77b Mon Sep 17 00:00:00 2001 From: Daniil Timizhev Date: Wed, 23 Jul 2025 16:08:31 +0300 Subject: [PATCH 03/17] f i x dots and words --- ydb/docs/en/core/concepts/_includes/transactions.md | 2 +- ydb/docs/ru/core/concepts/_includes/transactions.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/ydb/docs/en/core/concepts/_includes/transactions.md b/ydb/docs/en/core/concepts/_includes/transactions.md index e8eae2d6c62c..2a3779944add 100644 --- a/ydb/docs/en/core/concepts/_includes/transactions.md +++ b/ydb/docs/en/core/concepts/_includes/transactions.md @@ -32,7 +32,7 @@ The guarantees provided by implicit transactions are generally weaker than those DDL queries (such as `CREATE TABLE`, `DROP TABLE`, etc.) are always executed outside of any transaction context. Multistatement queries are supported only if all statements are DDL. If an error occurs, changes made by previous statements within the batch are not rolled back. - **Data Manipulation Language (DML) Statements** - DML queries (such as `INSERT`, `UPDATE`, `DELETE`, etc.) are automatically executed inside a transaction with Snapshot (for read-only queries) or Serializable (for read-write queries) isolation, created and managed by the server. Multistatement queries are supported if all statements are DML. On successful execution, changes are committed; if an error occurs, all changes are rolled back. + DML queries (such as `INSERT`, `UPDATE`, `DELETE`, etc.) are automatically executed inside a transaction with Snapshot (for read-only queries) or Serializable (for read-write queries) isolation, created and managed by the server. Multistatement queries are supported if all statements are DML. On successful execution, changes are committed. If an error occurs, all changes are rolled back. - **BATCH UPDATE / BATCH DELETE FROM Statements** Batch modification statements are executed outside of a transactional context. Multistatement queries are not supported. As with DDL, changes are not rolled back if an error occurs during execution. diff --git a/ydb/docs/ru/core/concepts/_includes/transactions.md b/ydb/docs/ru/core/concepts/_includes/transactions.md index 66fecdb2c0dd..95662a593584 100644 --- a/ydb/docs/ru/core/concepts/_includes/transactions.md +++ b/ydb/docs/ru/core/concepts/_includes/transactions.md @@ -27,10 +27,10 @@ Гарантии, которые предоставляют неявные транзакции, как правило, слабее, чем у явных. В частности, некоторые типы операций, выполненные через неявные транзакции, невозможно откатить в случае ошибки. Поведение зависит от типа оператора: - **Data Definition Language (DDL) операторы** - DDL-запросы (такие как `CREATE TABLE`, `DROP TABLE` и т.д.) всегда выполняются вне транзакционного контекста. Запросы, состоящие из нескольких операторов, поддерживаются только в том случае, если все они являются DDL. При возникновении ошибки изменения, внесенные предыдущими операторами в пакете, не отменяются (не откатываются). + DDL-запросы (такие как `CREATE TABLE`, `DROP TABLE` и т.д.) всегда выполняются вне транзакционного контекста. Запросы, состоящие из нескольких операторов, поддерживаются только в том случае, если все они являются DDL. При возникновении ошибки изменения, внесенные предыдущими операторами в пакете, не откатываются. - **Data Manipulation Language (DML) инструкции** - DML-запросы (такие как `INSERT`, `UPDATE`, `DELETE` и т.д.) автоматически выполняются внутри транзакции с уровнем изоляции Snapshot (для запросов только на чтение) или Serializable (для запросов на чтение-запись). Такая транзакция создается и управляется сервером. Поддерживаются запросы из нескольких инструкций, если все они являются DML. При успешном выполнении изменения коммитятся (фиксируются); в случае ошибки все изменения откатываются. + DML-запросы (такие как `INSERT`, `UPDATE`, `DELETE` и т.д.) автоматически выполняются внутри транзакции с уровнем изоляции Snapshot (для запросов только на чтение) или Serializable (для запросов на чтение-запись). Такая транзакция создается и управляется сервером. Поддерживаются запросы из нескольких инструкций, если все они являются DML. При успешном выполнении изменения коммитятся (фиксируются). При возникновении ошибки все изменения откатываются. - **Инструкции BATCH UPDATE / BATCH DELETE FROM** Операторы пакетного изменения выполняются вне транзакционного контекста. Запросы из нескольких операторов не поддерживаются. Как и в случае с DDL, при возникновении ошибки во время выполнения изменения не откатываются. From f815014393a8dab40f2a34ae010af521171ec1b3 Mon Sep 17 00:00:00 2001 From: Daniil Timizhev Date: Wed, 23 Jul 2025 16:27:25 +0300 Subject: [PATCH 04/17] fix query style --- ydb/docs/en/core/concepts/_includes/transactions.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ydb/docs/en/core/concepts/_includes/transactions.md b/ydb/docs/en/core/concepts/_includes/transactions.md index 2a3779944add..2de4a6e4d16d 100644 --- a/ydb/docs/en/core/concepts/_includes/transactions.md +++ b/ydb/docs/en/core/concepts/_includes/transactions.md @@ -39,11 +39,11 @@ The guarantees provided by implicit transactions are generally weaker than those **Summary Table** -| Statement Type | Implicit Transaction Handling | Multistatement Support | Rollback on Error | -|----------------|-----------------------------------------------|------------------------|-----------------------| -| DDL | Outside transaction context | Yes (DDL-only) | No | -| DML | Auto transaction (Serializable/Snapshot) | Yes (DML-only) | Yes | -| BATCH UPDATE / BATCH DELETE FROM | Outside transaction context | No | No | +| Statement Type | Implicit Transaction Handling | Multistatement Support | Rollback on Error | +|----------------|---------------------------------------------------|------------------------|-----------------------| +| DDL | Outside transaction context | Yes (DDL-only) | No | +| DML | Auto transaction (Serializable/Snapshot) | Yes (DML-only) | Yes | +| `BATCH UPDATE` / `BATCH DELETE FROM` | Outside transaction context | No | No | When using implicit transactions, be aware of these limitations and reduced guarantees compared to explicit transactions. For advanced transaction control, error handling, or atomicity across diverse statements, it is strongly recommended to use explicit transactions. From ae21d7c5ebb0581ae563975449d8a9eb5259ff6a Mon Sep 17 00:00:00 2001 From: Daniil Timizhev Date: Tue, 29 Jul 2025 20:40:20 +0300 Subject: [PATCH 05/17] Headers, batches and statements fixes --- .../core/concepts/_includes/transactions.md | 14 +++++------ .../core/concepts/_includes/transactions.md | 24 +++++++++---------- 2 files changed, 17 insertions(+), 21 deletions(-) diff --git a/ydb/docs/en/core/concepts/_includes/transactions.md b/ydb/docs/en/core/concepts/_includes/transactions.md index 2de4a6e4d16d..1617c2d6e523 100644 --- a/ydb/docs/en/core/concepts/_includes/transactions.md +++ b/ydb/docs/en/core/concepts/_includes/transactions.md @@ -24,7 +24,7 @@ If consistency or freshness requirement for data read by a transaction can be re When a transaction is not explicitly defined for a query, {{ ydb-short-name }} automatically manages transactional behavior. This is referred to as an implicit transaction. Unlike explicit transactions, where applications initiate and commit transactions directly, implicit transactions are internally handled by the {{ ydb-short-name }} server when no explicit transaction mode is specified. -**Behavior and Guarantees** +#### Behavior and Guarantees The guarantees provided by implicit transactions are generally weaker than those offered by explicit transactions. In particular, some types of operations executed via implicit transactions cannot be rolled back if an error occurs. The behavior varies depending on the type of statement: @@ -32,25 +32,23 @@ The guarantees provided by implicit transactions are generally weaker than those DDL queries (such as `CREATE TABLE`, `DROP TABLE`, etc.) are always executed outside of any transaction context. Multistatement queries are supported only if all statements are DDL. If an error occurs, changes made by previous statements within the batch are not rolled back. - **Data Manipulation Language (DML) Statements** - DML queries (such as `INSERT`, `UPDATE`, `DELETE`, etc.) are automatically executed inside a transaction with Snapshot (for read-only queries) or Serializable (for read-write queries) isolation, created and managed by the server. Multistatement queries are supported if all statements are DML. On successful execution, changes are committed. If an error occurs, all changes are rolled back. + DML queries (such as `UPSERT`, `INSERT`, `UPDATE`, `DELETE`, etc.) are automatically executed inside a transaction with Snapshot (for read-only queries) or Serializable (for read-write queries) isolation, created and managed by the server. Multistatement queries are supported if all statements are DML. On successful execution, changes are committed. If an error occurs, all changes are rolled back. -- **BATCH UPDATE / BATCH DELETE FROM Statements** - Batch modification statements are executed outside of a transactional context. Multistatement queries are not supported. As with DDL, changes are not rolled back if an error occurs during execution. +- **Batch Modification Statements** + Batch modification statements (such as `BATCH UPDATE` and `BATCH DELETE FROM`) are executed outside of a transactional context. Multistatement queries are not supported. As with DDL, changes are not rolled back if an error occurs during execution. -**Summary Table** +#### Summary Table | Statement Type | Implicit Transaction Handling | Multistatement Support | Rollback on Error | |----------------|---------------------------------------------------|------------------------|-----------------------| | DDL | Outside transaction context | Yes (DDL-only) | No | | DML | Auto transaction (Serializable/Snapshot) | Yes (DML-only) | Yes | -| `BATCH UPDATE` / `BATCH DELETE FROM` | Outside transaction context | No | No | +| Batch Modification Statements | Outside transaction context | No | No | When using implicit transactions, be aware of these limitations and reduced guarantees compared to explicit transactions. For advanced transaction control, error handling, or atomicity across diverse statements, it is strongly recommended to use explicit transactions. The transaction execution mode is specified in its settings when creating the transaction. See the examples for the {{ ydb-short-name }} SDK in the [{#T}](../../recipes/ydb-sdk/tx-control.md). ---- - ## YQL Language {#language-yql} Statements implemented in YQL can be divided into two classes: [Data Definition Language (DDL)](https://en.wikipedia.org/wiki/Data_definition_language) and [Data Manipulation Language (DML)](https://en.wikipedia.org/wiki/Data_manipulation_language). diff --git a/ydb/docs/ru/core/concepts/_includes/transactions.md b/ydb/docs/ru/core/concepts/_includes/transactions.md index 95662a593584..47f1d0d6dd6e 100644 --- a/ydb/docs/ru/core/concepts/_includes/transactions.md +++ b/ydb/docs/ru/core/concepts/_includes/transactions.md @@ -22,31 +22,29 @@ Если для запроса транзакция не определена явно, {{ ydb-short-name }} автоматически управляет транзакционным поведением. Такой подход называется неявной транзакцией. В отличие от явных транзакций, когда приложение напрямую инициирует и подтверждает транзакции, неявные транзакции обрабатываются внутренне сервером {{ ydb-short-name }}, если явный режим транзакции не задан. -**Поведение и гарантии** +#### Поведение и гарантии -Гарантии, которые предоставляют неявные транзакции, как правило, слабее, чем у явных. В частности, некоторые типы операций, выполненные через неявные транзакции, невозможно откатить в случае ошибки. Поведение зависит от типа оператора: +Гарантии, которые предоставляют неявные транзакции, как правило, слабее, чем у явных. В частности, некоторые типы операций, выполненные через неявные транзакции, невозможно откатить в случае ошибки. Поведение зависит от типа инструкции: -- **Data Definition Language (DDL) операторы** - DDL-запросы (такие как `CREATE TABLE`, `DROP TABLE` и т.д.) всегда выполняются вне транзакционного контекста. Запросы, состоящие из нескольких операторов, поддерживаются только в том случае, если все они являются DDL. При возникновении ошибки изменения, внесенные предыдущими операторами в пакете, не откатываются. +- **Инструкции Data Definition Language (DDL)** + DDL-запросы (такие как `CREATE TABLE`, `DROP TABLE` и т.д.) всегда выполняются вне транзакционного контекста. Запросы, состоящие из нескольких инструкций, поддерживаются только в том случае, если все они являются DDL. При возникновении ошибки изменения, внесенные предыдущими инструкциями в пакете, не откатываются. -- **Data Manipulation Language (DML) инструкции** - DML-запросы (такие как `INSERT`, `UPDATE`, `DELETE` и т.д.) автоматически выполняются внутри транзакции с уровнем изоляции Snapshot (для запросов только на чтение) или Serializable (для запросов на чтение-запись). Такая транзакция создается и управляется сервером. Поддерживаются запросы из нескольких инструкций, если все они являются DML. При успешном выполнении изменения коммитятся (фиксируются). При возникновении ошибки все изменения откатываются. +- **Инструкции Data Manipulation Language (DML)** + DML-запросы (такие как `UPSERT`, `INSERT`, `UPDATE`, `DELETE` и т.д.) автоматически выполняются внутри транзакции с уровнем изоляции Snapshot (для запросов только на чтение) или Serializable (для запросов на чтение-запись). Такая транзакция создается и управляется сервером. Поддерживаются запросы из нескольких инструкций, если все они являются DML. При успешном выполнении изменения коммитятся (фиксируются). При возникновении ошибки все изменения откатываются. -- **Инструкции BATCH UPDATE / BATCH DELETE FROM** - Операторы пакетного изменения выполняются вне транзакционного контекста. Запросы из нескольких операторов не поддерживаются. Как и в случае с DDL, при возникновении ошибки во время выполнения изменения не откатываются. +- **Инструкции пакетного изменения** + Инструкции пакетного изменения (такие как `BATCH UPDATE` и `BATCH DELETE FROM`) выполняются вне транзакционного контекста. Запросы из нескольких инструкций не поддерживаются. Как и в случае с DDL, при возникновении ошибки во время выполнения изменения не откатываются. -**Сводная таблица** +#### Сводная таблица -| Тип оператора | Обработка неявной транзакции | Поддержка нескольких операторов | Откат при ошибке | +| Тип инструкции | Обработка неявной транзакции | Поддержка нескольких инструкций | Откат при ошибке | |----------------|---------------------------------------------------|---------------------------------|-----------------------| | DDL | Вне транзакционного контекста | Да (только DDL) | Нет | | DML | Автоматическая транзакция (Serializable/Snapshot) | Да (только DML) | Да | -| `BATCH UPDATE` / `BATCH DELETE FROM` | Вне транзакционного контекста | Нет | Нет | +| Инструкции пакетного изменения | Вне транзакционного контекста | Нет | Нет | Режим выполнения транзакции задается в настройках транзакции при ее создании. Примеры для {{ ydb-short-name }} SDK смотрите в статье [{#T}](../../recipes/ydb-sdk/tx-control.md). ---- - ## Язык YQL {#language-yql} Реализованные конструкции YQL можно разделить на два класса: [data definition language (DDL)](https://en.wikipedia.org/wiki/Data_definition_language) и [data manipulation language (DML)](https://en.wikipedia.org/wiki/Data_manipulation_language). From 9bf20634db8e377e1e36f4feb86ede905216ab9b Mon Sep 17 00:00:00 2001 From: Daniil Timizhev Date: Wed, 30 Jul 2025 13:44:57 +0300 Subject: [PATCH 06/17] Links to modes --- ydb/docs/en/core/concepts/_includes/transactions.md | 6 +++--- ydb/docs/ru/core/concepts/_includes/transactions.md | 6 ++++-- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/ydb/docs/en/core/concepts/_includes/transactions.md b/ydb/docs/en/core/concepts/_includes/transactions.md index 1617c2d6e523..577f1792abe7 100644 --- a/ydb/docs/en/core/concepts/_includes/transactions.md +++ b/ydb/docs/en/core/concepts/_includes/transactions.md @@ -22,7 +22,7 @@ If consistency or freshness requirement for data read by a transaction can be re ### Implicit Transactions in {{ ydb-short-name }} {#implicit} -When a transaction is not explicitly defined for a query, {{ ydb-short-name }} automatically manages transactional behavior. This is referred to as an implicit transaction. Unlike explicit transactions, where applications initiate and commit transactions directly, implicit transactions are internally handled by the {{ ydb-short-name }} server when no explicit transaction mode is specified. +When a transaction is not explicitly defined for a query, {{ ydb-short-name }} automatically manages transactional behavior. This is referred to as an implicit transaction. Unlike explicit transactions, where applications initiate and commit transactions directly, implicit transactions are internally handled by the {{ ydb-short-name }} server when no [explicit transaction mode](../transactions.md#modes) is specified. #### Behavior and Guarantees @@ -32,7 +32,7 @@ The guarantees provided by implicit transactions are generally weaker than those DDL queries (such as `CREATE TABLE`, `DROP TABLE`, etc.) are always executed outside of any transaction context. Multistatement queries are supported only if all statements are DDL. If an error occurs, changes made by previous statements within the batch are not rolled back. - **Data Manipulation Language (DML) Statements** - DML queries (such as `UPSERT`, `INSERT`, `UPDATE`, `DELETE`, etc.) are automatically executed inside a transaction with Snapshot (for read-only queries) or Serializable (for read-write queries) isolation, created and managed by the server. Multistatement queries are supported if all statements are DML. On successful execution, changes are committed. If an error occurs, all changes are rolled back. + DML queries (such as `UPSERT`, `INSERT`, `UPDATE`, etc.) are automatically executed inside a transaction with Snapshot (for read-only queries) or Serializable (for read-write queries) isolation, created and managed by the server. Multistatement queries are supported if all statements are DML. On successful execution, changes are committed. If an error occurs, all changes are rolled back. - **Batch Modification Statements** Batch modification statements (such as `BATCH UPDATE` and `BATCH DELETE FROM`) are executed outside of a transactional context. Multistatement queries are not supported. As with DDL, changes are not rolled back if an error occurs during execution. @@ -45,7 +45,7 @@ The guarantees provided by implicit transactions are generally weaker than those | DML | Auto transaction (Serializable/Snapshot) | Yes (DML-only) | Yes | | Batch Modification Statements | Outside transaction context | No | No | -When using implicit transactions, be aware of these limitations and reduced guarantees compared to explicit transactions. For advanced transaction control, error handling, or atomicity across diverse statements, it is strongly recommended to use explicit transactions. +When using implicit transactions, be aware of these limitations and reduced guarantees compared to explicit transactions. For advanced transaction control, error handling, or atomicity across diverse statements, it is strongly recommended to use [explicit transactions mode](../transactions.md#modes). The transaction execution mode is specified in its settings when creating the transaction. See the examples for the {{ ydb-short-name }} SDK in the [{#T}](../../recipes/ydb-sdk/tx-control.md). diff --git a/ydb/docs/ru/core/concepts/_includes/transactions.md b/ydb/docs/ru/core/concepts/_includes/transactions.md index 47f1d0d6dd6e..20f16b814800 100644 --- a/ydb/docs/ru/core/concepts/_includes/transactions.md +++ b/ydb/docs/ru/core/concepts/_includes/transactions.md @@ -20,7 +20,7 @@ ### Неявные транзакции в {{ ydb-short-name }} {#implicit} -Если для запроса транзакция не определена явно, {{ ydb-short-name }} автоматически управляет транзакционным поведением. Такой подход называется неявной транзакцией. В отличие от явных транзакций, когда приложение напрямую инициирует и подтверждает транзакции, неявные транзакции обрабатываются внутренне сервером {{ ydb-short-name }}, если явный режим транзакции не задан. +Если для запроса транзакция не определена явно, {{ ydb-short-name }} автоматически управляет транзакционным поведением. Такой подход называется неявной транзакцией. В отличие от явных транзакций, когда приложение напрямую инициирует и подтверждает транзакции, неявные транзакции обрабатываются внутренне сервером {{ ydb-short-name }}, если [явный режим транзакции](../transactions.md#modes) не задан. #### Поведение и гарантии @@ -30,7 +30,7 @@ DDL-запросы (такие как `CREATE TABLE`, `DROP TABLE` и т.д.) всегда выполняются вне транзакционного контекста. Запросы, состоящие из нескольких инструкций, поддерживаются только в том случае, если все они являются DDL. При возникновении ошибки изменения, внесенные предыдущими инструкциями в пакете, не откатываются. - **Инструкции Data Manipulation Language (DML)** - DML-запросы (такие как `UPSERT`, `INSERT`, `UPDATE`, `DELETE` и т.д.) автоматически выполняются внутри транзакции с уровнем изоляции Snapshot (для запросов только на чтение) или Serializable (для запросов на чтение-запись). Такая транзакция создается и управляется сервером. Поддерживаются запросы из нескольких инструкций, если все они являются DML. При успешном выполнении изменения коммитятся (фиксируются). При возникновении ошибки все изменения откатываются. + DML-запросы (такие как `UPSERT`, `INSERT`, `UPDATE`, и т.д.) автоматически выполняются внутри транзакции с уровнем изоляции Snapshot (для запросов только на чтение) или Serializable (для запросов на чтение-запись). Такая транзакция создается и управляется сервером. Поддерживаются запросы из нескольких инструкций, если все они являются DML. При успешном выполнении изменения коммитятся (фиксируются). При возникновении ошибки все изменения откатываются. - **Инструкции пакетного изменения** Инструкции пакетного изменения (такие как `BATCH UPDATE` и `BATCH DELETE FROM`) выполняются вне транзакционного контекста. Запросы из нескольких инструкций не поддерживаются. Как и в случае с DDL, при возникновении ошибки во время выполнения изменения не откатываются. @@ -43,6 +43,8 @@ | DML | Автоматическая транзакция (Serializable/Snapshot) | Да (только DML) | Да | | Инструкции пакетного изменения | Вне транзакционного контекста | Нет | Нет | +При использовании неявных транзакций учитывайте эти ограничения и ослабленные гарантии по сравнению с явными транзакциями. Для расширенного управления транзакциями, обработки ошибок или обеспечения атомарности для разных инструкций настоятельно рекомендуется использовать [явный режим транзакции](../transactions.md#modes). + Режим выполнения транзакции задается в настройках транзакции при ее создании. Примеры для {{ ydb-short-name }} SDK смотрите в статье [{#T}](../../recipes/ydb-sdk/tx-control.md). ## Язык YQL {#language-yql} From c6d1d803e8bd618e315e2007c8289f60ccc7c7e6 Mon Sep 17 00:00:00 2001 From: Daniil Timizhev Date: Wed, 30 Jul 2025 14:02:44 +0300 Subject: [PATCH 07/17] TxControl to glossary --- ydb/docs/en/core/concepts/glossary.md | 2 ++ ydb/docs/ru/core/concepts/glossary.md | 2 ++ 2 files changed, 4 insertions(+) diff --git a/ydb/docs/en/core/concepts/glossary.md b/ydb/docs/en/core/concepts/glossary.md index 2f46a379a88c..b6e10a76e472 100644 --- a/ydb/docs/en/core/concepts/glossary.md +++ b/ydb/docs/en/core/concepts/glossary.md @@ -100,6 +100,8 @@ Technically, tablets are [actors](#actor) with a persistent state reliably saved Together, these mechanisms allow {{ ydb-short-name }} to provide [strict consistency](https://en.wikipedia.org/wiki/Consistency_model#Strict_consistency). +{{ ydb-short-name }} provides the ability to control transaction execution modes. You can explicitly define a transaction mode with specific isolation and consistency guarantees, or use implicit transactions, where {{ ydb-short-name }} automatically determines the appropriate transactional behavior based on the type of statements being executed. A detailed description of available transaction modes and their characteristics is provided in a separate article [{#T}](./transactions.md#modes). + The implementation of distributed transactions is covered in a separate article [{#T}](../contributor/datashard-distributed-txs.md), while below there's a list of several [related terms](#deterministic-transactions). ### Interactive transactions {#interactive-transaction} diff --git a/ydb/docs/ru/core/concepts/glossary.md b/ydb/docs/ru/core/concepts/glossary.md index fb8f27f0eae4..db9f5a870389 100644 --- a/ydb/docs/ru/core/concepts/glossary.md +++ b/ydb/docs/ru/core/concepts/glossary.md @@ -100,6 +100,8 @@ Эти механизмы позволяют {{ ydb-short-name }} обеспечивать [строгую согласованность](https://en.wikipedia.org/wiki/Consistency_model#Strict_consistency). +{{ ydb-short-name }} предоставляет возможность управления режимами выполнения транзакций. Есть возможность явно определить режим транзакции с конкретными гарантиями изоляции и консистентности, либо использовать неявные транзакции, при которых {{ ydb-short-name }} автоматически определяет подходящее транзакционное поведение в зависимости от типа выполняемых инструкций. Детальное описание доступных режимов транзакций и их характеристик представлено в разделе [{#T}](./transactions.md#modes). + {% if oss %} Реализация распределённых транзакций рассмотрена в отдельной статье [{#T}](../contributor/datashard-distributed-txs.md), а ниже приведён список нескольких [связанных терминов](#deterministic-transactions). From 973b2bb8b803bb21f03e212f2c9d01cbdd6c1c06 Mon Sep 17 00:00:00 2001 From: Daniil Timizhev Date: Thu, 7 Aug 2025 12:01:01 +0300 Subject: [PATCH 08/17] Explicit/implicit tx to glossary --- ydb/docs/en/core/concepts/glossary.md | 10 ++++++++-- ydb/docs/ru/core/concepts/glossary.md | 10 ++++++++-- 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/ydb/docs/en/core/concepts/glossary.md b/ydb/docs/en/core/concepts/glossary.md index b6e10a76e472..536dbf65f198 100644 --- a/ydb/docs/en/core/concepts/glossary.md +++ b/ydb/docs/en/core/concepts/glossary.md @@ -100,10 +100,16 @@ Technically, tablets are [actors](#actor) with a persistent state reliably saved Together, these mechanisms allow {{ ydb-short-name }} to provide [strict consistency](https://en.wikipedia.org/wiki/Consistency_model#Strict_consistency). -{{ ydb-short-name }} provides the ability to control transaction execution modes. You can explicitly define a transaction mode with specific isolation and consistency guarantees, or use implicit transactions, where {{ ydb-short-name }} automatically determines the appropriate transactional behavior based on the type of statements being executed. A detailed description of available transaction modes and their characteristics is provided in a separate article [{#T}](./transactions.md#modes). - The implementation of distributed transactions is covered in a separate article [{#T}](../contributor/datashard-distributed-txs.md), while below there's a list of several [related terms](#deterministic-transactions). +### Explicit Transactions {#explicit-transactions} + +Transactions that are explicitly defined and managed by the user are called **explicit transactions**. This type of transaction is initiated manually with selection of isolation level and transactional behavior. It is described in more detail in a separate article [{#T}](./transactions.md#modes). + +### Implicit Transactions {#implicit-transactions} + +Transactions that are automatically created and managed by {{ ydb-short-name }} when no transaction mode is specified are called **implicit transactions**. {{ ydb-short-name }} automatically determines the transactional behavior based on the provided query. It is described in more detail in a separate article [{#T}](./transactions.md#implicit). + ### Interactive transactions {#interactive-transaction} The term **interactive transactions** refers to transactions that are split into multiple queries and involve data processing by an application between these queries. For example: diff --git a/ydb/docs/ru/core/concepts/glossary.md b/ydb/docs/ru/core/concepts/glossary.md index db9f5a870389..7b28a874437e 100644 --- a/ydb/docs/ru/core/concepts/glossary.md +++ b/ydb/docs/ru/core/concepts/glossary.md @@ -100,14 +100,20 @@ Эти механизмы позволяют {{ ydb-short-name }} обеспечивать [строгую согласованность](https://en.wikipedia.org/wiki/Consistency_model#Strict_consistency). -{{ ydb-short-name }} предоставляет возможность управления режимами выполнения транзакций. Есть возможность явно определить режим транзакции с конкретными гарантиями изоляции и консистентности, либо использовать неявные транзакции, при которых {{ ydb-short-name }} автоматически определяет подходящее транзакционное поведение в зависимости от типа выполняемых инструкций. Детальное описание доступных режимов транзакций и их характеристик представлено в разделе [{#T}](./transactions.md#modes). - {% if oss %} Реализация распределённых транзакций рассмотрена в отдельной статье [{#T}](../contributor/datashard-distributed-txs.md), а ниже приведён список нескольких [связанных терминов](#deterministic-transactions). {% endif %} +### Явные транзакции {#explicit-transactions} + +Транзакции, которые явно определяются и управляются пользователем, называются **явными транзакциями**. Данный вид транзакций иницируется вручную с выбором уровня изоляции и транзакционными поведением. Они описаны более подробно в отдельной статье [{#T}](./transactions.md#modes). + +### Неявные транзакции {#implicit-transactions} + +Транзакции, которые автоматически создаются и управляются {{ ydb-short-name }}, когда режим транзакции не определен, называются **неявными транзакциями**. {{ ydb-short-name }} самостоятельно определяет транзакционное поведение в зависимости от переданного запроса. Они описаны более подробно в отдельной статье [{#T}](./transactions.md#implicit). + ### Многоверсионное управление параллелизмом {#mvcc} [**Многоверсионное управление параллелизмом**](https://ru.wikipedia.org/wiki/MVCC), **multi-version concurrency control** или **MVCC** — это метод, используемый {{ ydb-short-name }} для одновременного доступа нескольких параллельных транзакций к базе данных без взаимных помех. Он описан более подробно в отдельной статье [{#T}](mvcc.md). From 834ecce84287937fa5c3b151a828371361760ea0 Mon Sep 17 00:00:00 2001 From: Daniil Timizhev Date: Thu, 7 Aug 2025 17:06:54 +0300 Subject: [PATCH 09/17] Try to fix link to the implicit tx article --- ydb/docs/en/core/concepts/_includes/transactions.md | 2 +- ydb/docs/ru/core/concepts/_includes/transactions.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/ydb/docs/en/core/concepts/_includes/transactions.md b/ydb/docs/en/core/concepts/_includes/transactions.md index 577f1792abe7..f4b41b4aefb6 100644 --- a/ydb/docs/en/core/concepts/_includes/transactions.md +++ b/ydb/docs/en/core/concepts/_includes/transactions.md @@ -20,7 +20,7 @@ If consistency or freshness requirement for data read by a transaction can be re * *Stale Read-Only*: Read operations within a transaction may return results that are slightly out-of-date (lagging by fractions of a second). Each individual read returns consistent data, but no consistency between different reads is guaranteed. * *Snapshot Read-Only*: All the read operations within a transaction access the database snapshot. All the data reads are consistent. The snapshot is taken when the transaction begins, meaning the transaction sees all changes committed before it began. -### Implicit Transactions in {{ ydb-short-name }} {#implicit} +### Implicit Transactions {#implicit} When a transaction is not explicitly defined for a query, {{ ydb-short-name }} automatically manages transactional behavior. This is referred to as an implicit transaction. Unlike explicit transactions, where applications initiate and commit transactions directly, implicit transactions are internally handled by the {{ ydb-short-name }} server when no [explicit transaction mode](../transactions.md#modes) is specified. diff --git a/ydb/docs/ru/core/concepts/_includes/transactions.md b/ydb/docs/ru/core/concepts/_includes/transactions.md index 20f16b814800..4576eb83fa40 100644 --- a/ydb/docs/ru/core/concepts/_includes/transactions.md +++ b/ydb/docs/ru/core/concepts/_includes/transactions.md @@ -18,7 +18,7 @@ * *Stale Read-Only* — чтения данных в транзакции возвращают результаты с возможным отставанием от актуальных (доли секунды). Данные в каждом отдельно взятом чтении консистентны, между разными чтениями консистентность данных не гарантируется. * *Snapshot Read-Only* — все чтения транзакции производятся из снапшота базы данных, при этом все чтения данных консистентны. Взятие снапшота происходит в момент старта транзакции, т.е. транзакция видит все изменения, закоммиченные до момента своего начала. -### Неявные транзакции в {{ ydb-short-name }} {#implicit} +### Неявные транзакции {#implicit} Если для запроса транзакция не определена явно, {{ ydb-short-name }} автоматически управляет транзакционным поведением. Такой подход называется неявной транзакцией. В отличие от явных транзакций, когда приложение напрямую инициирует и подтверждает транзакции, неявные транзакции обрабатываются внутренне сервером {{ ydb-short-name }}, если [явный режим транзакции](../transactions.md#modes) не задан. From a50e6bbbbed9511af8c2c7e08abf9bc37deebe01 Mon Sep 17 00:00:00 2001 From: Daniil Timizhev Date: Thu, 7 Aug 2025 17:28:39 +0300 Subject: [PATCH 10/17] link to #implicit -> #modes --- ydb/docs/en/core/concepts/glossary.md | 4 ++-- ydb/docs/ru/core/concepts/glossary.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/ydb/docs/en/core/concepts/glossary.md b/ydb/docs/en/core/concepts/glossary.md index 536dbf65f198..84c86ac6517c 100644 --- a/ydb/docs/en/core/concepts/glossary.md +++ b/ydb/docs/en/core/concepts/glossary.md @@ -104,11 +104,11 @@ The implementation of distributed transactions is covered in a separate article ### Explicit Transactions {#explicit-transactions} -Transactions that are explicitly defined and managed by the user are called **explicit transactions**. This type of transaction is initiated manually with selection of isolation level and transactional behavior. It is described in more detail in a separate article [{#T}](./transactions.md#modes). +Transactions that are explicitly defined and managed by the user are called **explicit transactions**. This type of transaction is initiated manually with selection of isolation level and transactional behavior. They are explained in more detail in [{#T}](./transactions.md#modes). ### Implicit Transactions {#implicit-transactions} -Transactions that are automatically created and managed by {{ ydb-short-name }} when no transaction mode is specified are called **implicit transactions**. {{ ydb-short-name }} automatically determines the transactional behavior based on the provided query. It is described in more detail in a separate article [{#T}](./transactions.md#implicit). +Transactions that are automatically created and managed by {{ ydb-short-name }} when no transaction mode is specified are called **implicit transactions**. {{ ydb-short-name }} automatically determines the transactional behavior based on the provided query. They are explained in more detail in [{#T}](./transactions.md#modes). ### Interactive transactions {#interactive-transaction} diff --git a/ydb/docs/ru/core/concepts/glossary.md b/ydb/docs/ru/core/concepts/glossary.md index 7b28a874437e..dea541119064 100644 --- a/ydb/docs/ru/core/concepts/glossary.md +++ b/ydb/docs/ru/core/concepts/glossary.md @@ -108,11 +108,11 @@ ### Явные транзакции {#explicit-transactions} -Транзакции, которые явно определяются и управляются пользователем, называются **явными транзакциями**. Данный вид транзакций иницируется вручную с выбором уровня изоляции и транзакционными поведением. Они описаны более подробно в отдельной статье [{#T}](./transactions.md#modes). +Транзакции, которые явно определяются и управляются пользователем, называются **явными транзакциями**. Данный вид транзакций иницируется вручную с выбором уровня изоляции и транзакционными поведением. Они описаны более подробно в [{#T}](./transactions.md#modes). ### Неявные транзакции {#implicit-transactions} -Транзакции, которые автоматически создаются и управляются {{ ydb-short-name }}, когда режим транзакции не определен, называются **неявными транзакциями**. {{ ydb-short-name }} самостоятельно определяет транзакционное поведение в зависимости от переданного запроса. Они описаны более подробно в отдельной статье [{#T}](./transactions.md#implicit). +Транзакции, которые автоматически создаются и управляются {{ ydb-short-name }}, когда режим транзакции не определен, называются **неявными транзакциями**. {{ ydb-short-name }} самостоятельно определяет транзакционное поведение в зависимости от переданного запроса. Они описаны более подробно в [{#T}](./transactions.md#modes). ### Многоверсионное управление параллелизмом {#mvcc} From 6d9323818e55e1136307d8177b3f49a13b7e6cde Mon Sep 17 00:00:00 2001 From: Daniil Timizhev Date: Thu, 7 Aug 2025 18:10:29 +0300 Subject: [PATCH 11/17] ??? --- ydb/docs/en/core/concepts/glossary.md | 4 ++-- ydb/docs/ru/core/concepts/glossary.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/ydb/docs/en/core/concepts/glossary.md b/ydb/docs/en/core/concepts/glossary.md index 84c86ac6517c..09f8c4ceedac 100644 --- a/ydb/docs/en/core/concepts/glossary.md +++ b/ydb/docs/en/core/concepts/glossary.md @@ -104,11 +104,11 @@ The implementation of distributed transactions is covered in a separate article ### Explicit Transactions {#explicit-transactions} -Transactions that are explicitly defined and managed by the user are called **explicit transactions**. This type of transaction is initiated manually with selection of isolation level and transactional behavior. They are explained in more detail in [{#T}](./transactions.md#modes). +Transactions that are explicitly defined and managed by the user are called **explicit transactions**. This type of transaction is initiated manually with selection of isolation level and transactional behavior. They are explained in more detail in [{#T}](transactions.md#modes). ### Implicit Transactions {#implicit-transactions} -Transactions that are automatically created and managed by {{ ydb-short-name }} when no transaction mode is specified are called **implicit transactions**. {{ ydb-short-name }} automatically determines the transactional behavior based on the provided query. They are explained in more detail in [{#T}](./transactions.md#modes). +Transactions that are automatically created and managed by {{ ydb-short-name }} when no transaction mode is specified are called **implicit transactions**. {{ ydb-short-name }} automatically determines the transactional behavior based on the provided query. They are explained in more detail in [{#T}](transactions.md#implicit). ### Interactive transactions {#interactive-transaction} diff --git a/ydb/docs/ru/core/concepts/glossary.md b/ydb/docs/ru/core/concepts/glossary.md index dea541119064..65b0dbbfc2e1 100644 --- a/ydb/docs/ru/core/concepts/glossary.md +++ b/ydb/docs/ru/core/concepts/glossary.md @@ -108,11 +108,11 @@ ### Явные транзакции {#explicit-transactions} -Транзакции, которые явно определяются и управляются пользователем, называются **явными транзакциями**. Данный вид транзакций иницируется вручную с выбором уровня изоляции и транзакционными поведением. Они описаны более подробно в [{#T}](./transactions.md#modes). +Транзакции, которые явно определяются и управляются пользователем, называются **явными транзакциями**. Данный вид транзакций иницируется вручную с выбором уровня изоляции и транзакционными поведением. Они описаны более подробно в [{#T}](transactions.md#modes). ### Неявные транзакции {#implicit-transactions} -Транзакции, которые автоматически создаются и управляются {{ ydb-short-name }}, когда режим транзакции не определен, называются **неявными транзакциями**. {{ ydb-short-name }} самостоятельно определяет транзакционное поведение в зависимости от переданного запроса. Они описаны более подробно в [{#T}](./transactions.md#modes). +Транзакции, которые автоматически создаются и управляются {{ ydb-short-name }}, когда режим транзакции не определен, называются **неявными транзакциями**. {{ ydb-short-name }} самостоятельно определяет транзакционное поведение в зависимости от переданного запроса. Они описаны более подробно в [{#T}](transactions.md#implicit). ### Многоверсионное управление параллелизмом {#mvcc} From 9056217f84ebab5de94b56222729f04332f9c987 Mon Sep 17 00:00:00 2001 From: Ivan Blinkov Date: Tue, 12 Aug 2025 20:43:08 +0700 Subject: [PATCH 12/17] Apply suggestions from code review --- ydb/docs/en/core/concepts/glossary.md | 4 ++-- ydb/docs/ru/core/concepts/glossary.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/ydb/docs/en/core/concepts/glossary.md b/ydb/docs/en/core/concepts/glossary.md index 09f8c4ceedac..738f83c7c432 100644 --- a/ydb/docs/en/core/concepts/glossary.md +++ b/ydb/docs/en/core/concepts/glossary.md @@ -104,11 +104,11 @@ The implementation of distributed transactions is covered in a separate article ### Explicit Transactions {#explicit-transactions} -Transactions that are explicitly defined and managed by the user are called **explicit transactions**. This type of transaction is initiated manually with selection of isolation level and transactional behavior. They are explained in more detail in [{#T}](transactions.md#modes). +Transactions that are explicitly defined and managed by the user are called **explicit transactions**. This type of transaction is initiated manually, including the selection of the isolation level and transactional behavior. They are explained in more detail in [{#T}](transactions.md#modes). ### Implicit Transactions {#implicit-transactions} -Transactions that are automatically created and managed by {{ ydb-short-name }} when no transaction mode is specified are called **implicit transactions**. {{ ydb-short-name }} automatically determines the transactional behavior based on the provided query. They are explained in more detail in [{#T}](transactions.md#implicit). +Transactions that are automatically created and managed by {{ ydb-short-name }} are called **implicit transactions**. {{ ydb-short-name }} automatically determines the transactional behavior based on the provided query. They are explained in more detail in [{#T}](transactions.md#implicit). ### Interactive transactions {#interactive-transaction} diff --git a/ydb/docs/ru/core/concepts/glossary.md b/ydb/docs/ru/core/concepts/glossary.md index 65b0dbbfc2e1..7e73971c2ba1 100644 --- a/ydb/docs/ru/core/concepts/glossary.md +++ b/ydb/docs/ru/core/concepts/glossary.md @@ -108,11 +108,11 @@ ### Явные транзакции {#explicit-transactions} -Транзакции, которые явно определяются и управляются пользователем, называются **явными транзакциями**. Данный вид транзакций иницируется вручную с выбором уровня изоляции и транзакционными поведением. Они описаны более подробно в [{#T}](transactions.md#modes). +Транзакции, которые явно определяются и управляются пользователем, называются **явными транзакциями**. Данный вид транзакций инициируется вручную с выбором уровня изоляции и транзакционного поведения. Они описаны более подробно в [{#T}](transactions.md#modes). ### Неявные транзакции {#implicit-transactions} -Транзакции, которые автоматически создаются и управляются {{ ydb-short-name }}, когда режим транзакции не определен, называются **неявными транзакциями**. {{ ydb-short-name }} самостоятельно определяет транзакционное поведение в зависимости от переданного запроса. Они описаны более подробно в [{#T}](transactions.md#implicit). +Транзакции, которые автоматически создаются и управляются {{ ydb-short-name }}, называются **неявными транзакциями**. {{ ydb-short-name }} самостоятельно определяет транзакционное поведение в зависимости от переданного запроса. Они описаны более подробно в [{#T}](transactions.md#implicit). ### Многоверсионное управление параллелизмом {#mvcc} From f319621af71227b782dfe15fd989a9812cca1095 Mon Sep 17 00:00:00 2001 From: Daniil Timizhev Date: Mon, 1 Sep 2025 15:34:02 +0300 Subject: [PATCH 13/17] Simplify implicit tx --- .../core/concepts/_includes/transactions.md | 20 +++++++++---------- ydb/docs/en/core/concepts/glossary.md | 6 +----- .../core/concepts/_includes/transactions.md | 20 +++++++++---------- ydb/docs/ru/core/concepts/glossary.md | 6 +----- 4 files changed, 20 insertions(+), 32 deletions(-) diff --git a/ydb/docs/en/core/concepts/_includes/transactions.md b/ydb/docs/en/core/concepts/_includes/transactions.md index f4b41b4aefb6..f047ae9d9100 100644 --- a/ydb/docs/en/core/concepts/_includes/transactions.md +++ b/ydb/docs/en/core/concepts/_includes/transactions.md @@ -22,30 +22,28 @@ If consistency or freshness requirement for data read by a transaction can be re ### Implicit Transactions {#implicit} -When a transaction is not explicitly defined for a query, {{ ydb-short-name }} automatically manages transactional behavior. This is referred to as an implicit transaction. Unlike explicit transactions, where applications initiate and commit transactions directly, implicit transactions are internally handled by the {{ ydb-short-name }} server when no [explicit transaction mode](../transactions.md#modes) is specified. +If no [transaction mode](../transactions.md#modes) is specified for a query, {{ ydb-short-name }} automatically manages its behavior. This mode is called an **implicit transaction**. -#### Behavior and Guarantees +In this mode, based on the query, {{ ydb-short-name }} decides whether to execute it outside a transaction or wrap it in a transaction with **Serializable** mode. Implicit transactions are a universal way to execute queries, as they support statements of any kind with certain guarantees and limitations described below. -The guarantees provided by implicit transactions are generally weaker than those offered by explicit transactions. In particular, some types of operations executed via implicit transactions cannot be rolled back if an error occurs. The behavior varies depending on the type of statement: +#### Behavior and Guarantees - **Data Definition Language (DDL) Statements** - DDL queries (such as `CREATE TABLE`, `DROP TABLE`, etc.) are always executed outside of any transaction context. Multistatement queries are supported only if all statements are DDL. If an error occurs, changes made by previous statements within the batch are not rolled back. + DDL statements (such as `CREATE TABLE`, `DROP TABLE`, etc.) are always executed outside a transaction. A query can consist only of DDL statements. If an error occurs, changes made by previous statements in the query are not rolled back. - **Data Manipulation Language (DML) Statements** - DML queries (such as `UPSERT`, `INSERT`, `UPDATE`, etc.) are automatically executed inside a transaction with Snapshot (for read-only queries) or Serializable (for read-write queries) isolation, created and managed by the server. Multistatement queries are supported if all statements are DML. On successful execution, changes are committed. If an error occurs, all changes are rolled back. + DML statements (such as `UPSERT`, `INSERT`, `UPDATE`, etc.) are wrapped in a transaction with **Serializable** mode. A query can consist only of DML statements. On success, changes are committed. If an error occurs, all changes rolled back. - **Batch Modification Statements** - Batch modification statements (such as `BATCH UPDATE` and `BATCH DELETE FROM`) are executed outside of a transactional context. Multistatement queries are not supported. As with DDL, changes are not rolled back if an error occurs during execution. + Batch modification statements (such as `BATCH UPDATE` and `BATCH DELETE FROM`) are executed outside a transaction. A query can contain only one batch modification statement. If an error occurs, the statement's changes are not rolled back. #### Summary Table | Statement Type | Implicit Transaction Handling | Multistatement Support | Rollback on Error | |----------------|---------------------------------------------------|------------------------|-----------------------| -| DDL | Outside transaction context | Yes (DDL-only) | No | -| DML | Auto transaction (Serializable/Snapshot) | Yes (DML-only) | Yes | -| Batch Modification Statements | Outside transaction context | No | No | - -When using implicit transactions, be aware of these limitations and reduced guarantees compared to explicit transactions. For advanced transaction control, error handling, or atomicity across diverse statements, it is strongly recommended to use [explicit transactions mode](../transactions.md#modes). +| DDL | Outside a transaction | Yes (DDL-only) | No | +| DML | Auto transaction (Serializable) | Yes (DML-only) | Yes | +| Batch Modification Statements | Outside a transaction | No | No | The transaction execution mode is specified in its settings when creating the transaction. See the examples for the {{ ydb-short-name }} SDK in the [{#T}](../../recipes/ydb-sdk/tx-control.md). diff --git a/ydb/docs/en/core/concepts/glossary.md b/ydb/docs/en/core/concepts/glossary.md index 738f83c7c432..273ab55654a5 100644 --- a/ydb/docs/en/core/concepts/glossary.md +++ b/ydb/docs/en/core/concepts/glossary.md @@ -102,13 +102,9 @@ Together, these mechanisms allow {{ ydb-short-name }} to provide [strict consist The implementation of distributed transactions is covered in a separate article [{#T}](../contributor/datashard-distributed-txs.md), while below there's a list of several [related terms](#deterministic-transactions). -### Explicit Transactions {#explicit-transactions} - -Transactions that are explicitly defined and managed by the user are called **explicit transactions**. This type of transaction is initiated manually, including the selection of the isolation level and transactional behavior. They are explained in more detail in [{#T}](transactions.md#modes). - ### Implicit Transactions {#implicit-transactions} -Transactions that are automatically created and managed by {{ ydb-short-name }} are called **implicit transactions**. {{ ydb-short-name }} automatically determines the transactional behavior based on the provided query. They are explained in more detail in [{#T}](transactions.md#implicit). +An **implicit transaction** is the query execution mode used when the [transaction mode](transactions.md#modes) is not specified. {{ ydb-short-name }} automatically determines the behavior for each statement — whether to wrap it in a transaction or execute it outside one. This mode is described in more detail in [{#T}](transactions.md#implicit). ### Interactive transactions {#interactive-transaction} diff --git a/ydb/docs/ru/core/concepts/_includes/transactions.md b/ydb/docs/ru/core/concepts/_includes/transactions.md index 4576eb83fa40..aaf6ed92b46a 100644 --- a/ydb/docs/ru/core/concepts/_includes/transactions.md +++ b/ydb/docs/ru/core/concepts/_includes/transactions.md @@ -20,30 +20,28 @@ ### Неявные транзакции {#implicit} -Если для запроса транзакция не определена явно, {{ ydb-short-name }} автоматически управляет транзакционным поведением. Такой подход называется неявной транзакцией. В отличие от явных транзакций, когда приложение напрямую инициирует и подтверждает транзакции, неявные транзакции обрабатываются внутренне сервером {{ ydb-short-name }}, если [явный режим транзакции](../transactions.md#modes) не задан. +Если для запроса не задан [режим транзакции](../transactions.md#modes), {{ ydb-short-name }} автоматически управляет его поведением. Такой режим называется неявной транзакцией. -#### Поведение и гарантии +В этом режиме {{ ydb-short-name }} на основе запроса определяет, выполнить его вне транзакции или обернуть в транзакцию с режимом *Serializable*. Режим неявной транзакции является универсальным для выполнения запроса, так как поддерживает инструкции любого вида с некоторыми гарантиями и ограничениями, описанными ниже. -Гарантии, которые предоставляют неявные транзакции, как правило, слабее, чем у явных. В частности, некоторые типы операций, выполненные через неявные транзакции, невозможно откатить в случае ошибки. Поведение зависит от типа инструкции: +#### Поведение и гарантии - **Инструкции Data Definition Language (DDL)** - DDL-запросы (такие как `CREATE TABLE`, `DROP TABLE` и т.д.) всегда выполняются вне транзакционного контекста. Запросы, состоящие из нескольких инструкций, поддерживаются только в том случае, если все они являются DDL. При возникновении ошибки изменения, внесенные предыдущими инструкциями в пакете, не откатываются. + DDL-инструкции (такие как `CREATE TABLE`, `DROP TABLE` и т.д.) всегда выполняются вне транзакции. Запрос может состоять только из DDL инструкций. При возникновении ошибки изменения, внесенные предыдущими инструкциями запроса, не откатываются. - **Инструкции Data Manipulation Language (DML)** - DML-запросы (такие как `UPSERT`, `INSERT`, `UPDATE`, и т.д.) автоматически выполняются внутри транзакции с уровнем изоляции Snapshot (для запросов только на чтение) или Serializable (для запросов на чтение-запись). Такая транзакция создается и управляется сервером. Поддерживаются запросы из нескольких инструкций, если все они являются DML. При успешном выполнении изменения коммитятся (фиксируются). При возникновении ошибки все изменения откатываются. + DML-инструкции (такие как `UPSERT`, `INSERT`, `UPDATE`, и т.д.) оборачиваются в транзакцию с режимом *Serializable*. Запрос может состоять только из DML инструкций. При успешном выполнении изменения коммитятся (фиксируются), а при возникновении ошибки откатываются. - **Инструкции пакетного изменения** - Инструкции пакетного изменения (такие как `BATCH UPDATE` и `BATCH DELETE FROM`) выполняются вне транзакционного контекста. Запросы из нескольких инструкций не поддерживаются. Как и в случае с DDL, при возникновении ошибки во время выполнения изменения не откатываются. + Инструкции пакетного изменения (такие как `BATCH UPDATE` и `BATCH DELETE FROM`) выполняются вне транзакции. Запрос может состоять только из одной инструкции пакетного изменения. При возникновении ошибки изменения инструкции не откатываются. #### Сводная таблица | Тип инструкции | Обработка неявной транзакции | Поддержка нескольких инструкций | Откат при ошибке | |----------------|---------------------------------------------------|---------------------------------|-----------------------| -| DDL | Вне транзакционного контекста | Да (только DDL) | Нет | -| DML | Автоматическая транзакция (Serializable/Snapshot) | Да (только DML) | Да | -| Инструкции пакетного изменения | Вне транзакционного контекста | Нет | Нет | - -При использовании неявных транзакций учитывайте эти ограничения и ослабленные гарантии по сравнению с явными транзакциями. Для расширенного управления транзакциями, обработки ошибок или обеспечения атомарности для разных инструкций настоятельно рекомендуется использовать [явный режим транзакции](../transactions.md#modes). +| DDL | Вне транзакции | Да (только DDL) | Нет | +| DML | Автоматическая транзакция (Serializable) | Да (только DML) | Да | +| Инструкции пакетного изменения | Вне транзакции | Нет | Нет | Режим выполнения транзакции задается в настройках транзакции при ее создании. Примеры для {{ ydb-short-name }} SDK смотрите в статье [{#T}](../../recipes/ydb-sdk/tx-control.md). diff --git a/ydb/docs/ru/core/concepts/glossary.md b/ydb/docs/ru/core/concepts/glossary.md index 7e73971c2ba1..cb0fa67c32ae 100644 --- a/ydb/docs/ru/core/concepts/glossary.md +++ b/ydb/docs/ru/core/concepts/glossary.md @@ -106,13 +106,9 @@ {% endif %} -### Явные транзакции {#explicit-transactions} - -Транзакции, которые явно определяются и управляются пользователем, называются **явными транзакциями**. Данный вид транзакций инициируется вручную с выбором уровня изоляции и транзакционного поведения. Они описаны более подробно в [{#T}](transactions.md#modes). - ### Неявные транзакции {#implicit-transactions} -Транзакции, которые автоматически создаются и управляются {{ ydb-short-name }}, называются **неявными транзакциями**. {{ ydb-short-name }} самостоятельно определяет транзакционное поведение в зависимости от переданного запроса. Они описаны более подробно в [{#T}](transactions.md#implicit). +**Неявной транзакций** называется режим выполнения запроса, когда [режим транзакции](transactions.md#modes) не указан. {{ ydb-short-name }} самостоятельно определяет поведение для инструкций — обернуть их в транзакцию или нет. Данный режим описан более подробно в [{#T}](transactions.md#implicit). ### Многоверсионное управление параллелизмом {#mvcc} From 69d4bbd8696b2d077ed9835b7c2a549e01502738 Mon Sep 17 00:00:00 2001 From: Daniil Timizhev Date: Mon, 1 Sep 2025 16:12:52 +0300 Subject: [PATCH 14/17] Small fixes --- ydb/docs/en/core/concepts/_includes/transactions.md | 6 +++--- ydb/docs/ru/core/concepts/_includes/transactions.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/ydb/docs/en/core/concepts/_includes/transactions.md b/ydb/docs/en/core/concepts/_includes/transactions.md index f047ae9d9100..dd013e680023 100644 --- a/ydb/docs/en/core/concepts/_includes/transactions.md +++ b/ydb/docs/en/core/concepts/_includes/transactions.md @@ -24,15 +24,15 @@ If consistency or freshness requirement for data read by a transaction can be re If no [transaction mode](../transactions.md#modes) is specified for a query, {{ ydb-short-name }} automatically manages its behavior. This mode is called an **implicit transaction**. -In this mode, based on the query, {{ ydb-short-name }} decides whether to execute it outside a transaction or wrap it in a transaction with **Serializable** mode. Implicit transactions are a universal way to execute queries, as they support statements of any kind with certain guarantees and limitations described below. +In this mode, based on the query, {{ ydb-short-name }} decides whether to execute it outside a transaction or wrap it in a transaction with *Serializable* mode. Implicit transactions are a universal way to execute queries, as they support statements of any kind with certain guarantees and limitations described below. #### Behavior and Guarantees - **Data Definition Language (DDL) Statements** - DDL statements (such as `CREATE TABLE`, `DROP TABLE`, etc.) are always executed outside a transaction. A query can consist only of DDL statements. If an error occurs, changes made by previous statements in the query are not rolled back. + DDL statements (such as `CREATE TABLE`, `DROP TABLE`, etc.) are executed outside a transaction. A query can consist only of DDL statements. If an error occurs, changes made by previous statements in the query are not rolled back. - **Data Manipulation Language (DML) Statements** - DML statements (such as `UPSERT`, `INSERT`, `UPDATE`, etc.) are wrapped in a transaction with **Serializable** mode. A query can consist only of DML statements. On success, changes are committed. If an error occurs, all changes rolled back. + DML statements (such as `UPSERT`, `INSERT`, `UPDATE`, etc.) are wrapped in a transaction with *Serializable* mode. A query can consist only of DML statements. On success, changes are committed. If an error occurs, all changes rolled back. - **Batch Modification Statements** Batch modification statements (such as `BATCH UPDATE` and `BATCH DELETE FROM`) are executed outside a transaction. A query can contain only one batch modification statement. If an error occurs, the statement's changes are not rolled back. diff --git a/ydb/docs/ru/core/concepts/_includes/transactions.md b/ydb/docs/ru/core/concepts/_includes/transactions.md index aaf6ed92b46a..decd204c2138 100644 --- a/ydb/docs/ru/core/concepts/_includes/transactions.md +++ b/ydb/docs/ru/core/concepts/_includes/transactions.md @@ -27,7 +27,7 @@ #### Поведение и гарантии - **Инструкции Data Definition Language (DDL)** - DDL-инструкции (такие как `CREATE TABLE`, `DROP TABLE` и т.д.) всегда выполняются вне транзакции. Запрос может состоять только из DDL инструкций. При возникновении ошибки изменения, внесенные предыдущими инструкциями запроса, не откатываются. + DDL-инструкции (такие как `CREATE TABLE`, `DROP TABLE` и т.д.) выполняются вне транзакции. Запрос может состоять только из DDL инструкций. При возникновении ошибки изменения, внесенные предыдущими инструкциями запроса, не откатываются. - **Инструкции Data Manipulation Language (DML)** DML-инструкции (такие как `UPSERT`, `INSERT`, `UPDATE`, и т.д.) оборачиваются в транзакцию с режимом *Serializable*. Запрос может состоять только из DML инструкций. При успешном выполнении изменения коммитятся (фиксируются), а при возникновении ошибки откатываются. From ad3cd1cbf079d0f1886e1122b7ca507e894587d7 Mon Sep 17 00:00:00 2001 From: Daniil Timizhev Date: Tue, 2 Sep 2025 15:15:51 +0300 Subject: [PATCH 15/17] Fixes after review --- .../en/core/concepts/_includes/transactions.md | 14 +++++++------- .../ru/core/concepts/_includes/transactions.md | 14 +++++++------- ydb/docs/ru/core/concepts/glossary.md | 2 +- .../ru/core/yql/reference/syntax/batch-delete.md | 2 +- .../ru/core/yql/reference/syntax/batch-update.md | 2 +- 5 files changed, 17 insertions(+), 17 deletions(-) diff --git a/ydb/docs/en/core/concepts/_includes/transactions.md b/ydb/docs/en/core/concepts/_includes/transactions.md index dd013e680023..ed27f500cc67 100644 --- a/ydb/docs/en/core/concepts/_includes/transactions.md +++ b/ydb/docs/en/core/concepts/_includes/transactions.md @@ -24,18 +24,18 @@ If consistency or freshness requirement for data read by a transaction can be re If no [transaction mode](../transactions.md#modes) is specified for a query, {{ ydb-short-name }} automatically manages its behavior. This mode is called an **implicit transaction**. -In this mode, based on the query, {{ ydb-short-name }} decides whether to execute it outside a transaction or wrap it in a transaction with *Serializable* mode. Implicit transactions are a universal way to execute queries, as they support statements of any kind with certain guarantees and limitations described below. +In this mode, based on the query, {{ ydb-short-name }} decides whether to execute it outside a transaction or wrap it in a transaction with *Serializable* mode. Implicit transactions are a universal way to execute queries, as they support statements of any kind with certain behaviors described below. -#### Behavior and Guarantees +#### Behavior for different types of statements -- **Data Definition Language (DDL) Statements** - DDL statements (such as `CREATE TABLE`, `DROP TABLE`, etc.) are executed outside a transaction. A query can consist only of DDL statements. If an error occurs, changes made by previous statements in the query are not rolled back. +- **[Data Definition Language](https://en.wikipedia.org/wiki/Data_definition_language) (DDL) Statements** + DDL statements (such as [CREATE TABLE](../../yql/reference/syntax/create_table/index.md), [DROP TABLE](../../yql/reference/syntax/drop_table.md), etc.) are executed outside a transaction. A query can consist only of DDL statements. If an error occurs, changes made by previous statements in the query are not rolled back. -- **Data Manipulation Language (DML) Statements** - DML statements (such as `UPSERT`, `INSERT`, `UPDATE`, etc.) are wrapped in a transaction with *Serializable* mode. A query can consist only of DML statements. On success, changes are committed. If an error occurs, all changes rolled back. +- **[Data Manipulation Language](https://en.wikipedia.org/wiki/Data_manipulation_language) (DML) Statements** + DML statements (such as [UPSERT](../../yql/reference/syntax/upsert_into.md), [SELECT](../../yql/reference/syntax/select/index.md), [UPDATE](../../yql/reference/syntax/update.md), etc.) are wrapped in a transaction with *Serializable* mode. A query can consist only of DML statements. On success, changes are committed. If an error occurs, all changes are rolled back. - **Batch Modification Statements** - Batch modification statements (such as `BATCH UPDATE` and `BATCH DELETE FROM`) are executed outside a transaction. A query can contain only one batch modification statement. If an error occurs, the statement's changes are not rolled back. + Batch modification statements (such as [BATCH UPDATE](../../yql/reference/syntax/batch-update.md) and [BATCH DELETE FROM](../../yql/reference/syntax/batch-delete.md)) are executed outside a transaction. A query can contain only one batch modification statement. If an error occurs, the statement's changes are not rolled back. #### Summary Table diff --git a/ydb/docs/ru/core/concepts/_includes/transactions.md b/ydb/docs/ru/core/concepts/_includes/transactions.md index decd204c2138..5b4f672a481d 100644 --- a/ydb/docs/ru/core/concepts/_includes/transactions.md +++ b/ydb/docs/ru/core/concepts/_includes/transactions.md @@ -22,18 +22,18 @@ Если для запроса не задан [режим транзакции](../transactions.md#modes), {{ ydb-short-name }} автоматически управляет его поведением. Такой режим называется неявной транзакцией. -В этом режиме {{ ydb-short-name }} на основе запроса определяет, выполнить его вне транзакции или обернуть в транзакцию с режимом *Serializable*. Режим неявной транзакции является универсальным для выполнения запроса, так как поддерживает инструкции любого вида с некоторыми гарантиями и ограничениями, описанными ниже. +В этом режиме {{ ydb-short-name }} на основе запроса определяет, выполнить его вне транзакции или обернуть в транзакцию с режимом *Serializable*. Режим неявной транзакции является универсальным для выполнения запроса, так как поддерживает инструкции любого вида с определёнными поведениями, описанными ниже. -#### Поведение и гарантии +#### Поведение для разных видов инструкций -- **Инструкции Data Definition Language (DDL)** - DDL-инструкции (такие как `CREATE TABLE`, `DROP TABLE` и т.д.) выполняются вне транзакции. Запрос может состоять только из DDL инструкций. При возникновении ошибки изменения, внесенные предыдущими инструкциями запроса, не откатываются. +- **Инструкции [Data Definition Language](https://en.wikipedia.org/wiki/Data_definition_language) (DDL)** + DDL-инструкции (такие как [CREATE TABLE](../../yql/reference/syntax/create_table/index.md), [DROP TABLE](../../yql/reference/syntax/drop_table.md) и т.д.) выполняются вне транзакции. Запрос может состоять только из DDL-инструкций. При возникновении ошибки изменения, внесённые предыдущими инструкциями запроса, не откатываются. -- **Инструкции Data Manipulation Language (DML)** - DML-инструкции (такие как `UPSERT`, `INSERT`, `UPDATE`, и т.д.) оборачиваются в транзакцию с режимом *Serializable*. Запрос может состоять только из DML инструкций. При успешном выполнении изменения коммитятся (фиксируются), а при возникновении ошибки откатываются. +- **Инструкции [Data Manipulation Language](https://en.wikipedia.org/wiki/Data_manipulation_language) (DML)** + DML-инструкции (такие как [UPSERT](../../yql/reference/syntax/upsert_into.md), [SELECT](../../yql/reference/syntax/select/index.md), [UPDATE](../../yql/reference/syntax/update.md) и т.д.) оборачиваются в транзакцию с режимом *Serializable*. Запрос может состоять только из DML-инструкций. При успешном выполнении изменения коммитятся (фиксируются), а при возникновении ошибки — откатываются. - **Инструкции пакетного изменения** - Инструкции пакетного изменения (такие как `BATCH UPDATE` и `BATCH DELETE FROM`) выполняются вне транзакции. Запрос может состоять только из одной инструкции пакетного изменения. При возникновении ошибки изменения инструкции не откатываются. + Инструкции пакетного изменения (такие как [BATCH UPDATE](../../yql/reference/syntax/batch-update.md) и [BATCH DELETE FROM](../../yql/reference/syntax/batch-delete.md)) выполняются вне транзакции. Запрос может состоять только из одной инструкции пакетного изменения. При возникновении ошибки изменения инструкции не откатываются. #### Сводная таблица diff --git a/ydb/docs/ru/core/concepts/glossary.md b/ydb/docs/ru/core/concepts/glossary.md index cb0fa67c32ae..eb66f0a23094 100644 --- a/ydb/docs/ru/core/concepts/glossary.md +++ b/ydb/docs/ru/core/concepts/glossary.md @@ -108,7 +108,7 @@ ### Неявные транзакции {#implicit-transactions} -**Неявной транзакций** называется режим выполнения запроса, когда [режим транзакции](transactions.md#modes) не указан. {{ ydb-short-name }} самостоятельно определяет поведение для инструкций — обернуть их в транзакцию или нет. Данный режим описан более подробно в [{#T}](transactions.md#implicit). +**Неявная транзакция** — это режим выполнения запросов, при котором [режим транзакции](transactions.md#modes) не указан. В этом случае {{ ydb-short-name }} самостоятельно определяет, нужно ли обернуть их в транзакцию. Этот режим описан более подробно в [{#T}](transactions.md#implicit). ### Многоверсионное управление параллелизмом {#mvcc} diff --git a/ydb/docs/ru/core/yql/reference/syntax/batch-delete.md b/ydb/docs/ru/core/yql/reference/syntax/batch-delete.md index 78924e5c694f..f6e1a1dafc2a 100644 --- a/ydb/docs/ru/core/yql/reference/syntax/batch-delete.md +++ b/ydb/docs/ru/core/yql/reference/syntax/batch-delete.md @@ -13,7 +13,7 @@ Семантика наследуется от стандартного `DELETE FROM` с ограничениями: * Поддерживается только для [строковых таблиц](../../../concepts/glossary.md#row-oriented-table). -* Поддерживается только для режима [неявного контроля транзакций](../../../concepts/transactions.md#implicit). +* Поддерживается только в режиме [неявного контроля транзакций](../../../concepts/transactions.md#implicit). * Запрещено использование подзапросов и нескольких выражений в одном запросе. * Недоступно ключевое слово `RETURNING`. diff --git a/ydb/docs/ru/core/yql/reference/syntax/batch-update.md b/ydb/docs/ru/core/yql/reference/syntax/batch-update.md index cf63547703d1..97f32b680070 100644 --- a/ydb/docs/ru/core/yql/reference/syntax/batch-update.md +++ b/ydb/docs/ru/core/yql/reference/syntax/batch-update.md @@ -14,7 +14,7 @@ Семантика наследуется от стандартного `UPDATE` с ограничениями: * Поддерживается только для [строковых таблиц](../../../concepts/glossary.md#row-oriented-table). -* Поддерживается только для режима [неявного контроля транзакций](../../../concepts/transactions.md#implicit). +* Поддерживается только в режиме [неявного контроля транзакций](../../../concepts/transactions.md#implicit). * Поддерживаются только идемпотентные обновления: выражения после `SET` не должны зависеть от текущих значений изменяемых колонок. * Запрещено использование подзапросов и нескольких выражений в одном запросе. * Недоступно ключевое слово `RETURNING`. From 3b9f42daa84710926191cfd3c55afb1e1ad97ef2 Mon Sep 17 00:00:00 2001 From: Daniil Timizhev Date: Tue, 2 Sep 2025 15:47:25 +0300 Subject: [PATCH 16/17] Behavior fixes --- ydb/docs/en/core/concepts/_includes/transactions.md | 2 +- ydb/docs/ru/core/concepts/_includes/transactions.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/ydb/docs/en/core/concepts/_includes/transactions.md b/ydb/docs/en/core/concepts/_includes/transactions.md index ed27f500cc67..de8148c71f6c 100644 --- a/ydb/docs/en/core/concepts/_includes/transactions.md +++ b/ydb/docs/en/core/concepts/_includes/transactions.md @@ -24,7 +24,7 @@ If consistency or freshness requirement for data read by a transaction can be re If no [transaction mode](../transactions.md#modes) is specified for a query, {{ ydb-short-name }} automatically manages its behavior. This mode is called an **implicit transaction**. -In this mode, based on the query, {{ ydb-short-name }} decides whether to execute it outside a transaction or wrap it in a transaction with *Serializable* mode. Implicit transactions are a universal way to execute queries, as they support statements of any kind with certain behaviors described below. +In this mode, based on the query, {{ ydb-short-name }} decides whether to execute it outside a transaction or wrap it in a transaction with *Serializable* mode. Implicit transactions are a universal way to execute queries, as they support statements of any kind with a certain behavior described below. #### Behavior for different types of statements diff --git a/ydb/docs/ru/core/concepts/_includes/transactions.md b/ydb/docs/ru/core/concepts/_includes/transactions.md index 5b4f672a481d..911e210cd8df 100644 --- a/ydb/docs/ru/core/concepts/_includes/transactions.md +++ b/ydb/docs/ru/core/concepts/_includes/transactions.md @@ -22,7 +22,7 @@ Если для запроса не задан [режим транзакции](../transactions.md#modes), {{ ydb-short-name }} автоматически управляет его поведением. Такой режим называется неявной транзакцией. -В этом режиме {{ ydb-short-name }} на основе запроса определяет, выполнить его вне транзакции или обернуть в транзакцию с режимом *Serializable*. Режим неявной транзакции является универсальным для выполнения запроса, так как поддерживает инструкции любого вида с определёнными поведениями, описанными ниже. +В этом режиме {{ ydb-short-name }} на основе запроса определяет, выполнить его вне транзакции или обернуть в транзакцию с режимом *Serializable*. Режим неявной транзакции является универсальным для выполнения запроса, так как поддерживает инструкции любого вида с определённым поведением, описанным ниже. #### Поведение для разных видов инструкций From a77131f817950e4af8626d1f0c8b4c1422805c4e Mon Sep 17 00:00:00 2001 From: Ivan Blinkov Date: Mon, 8 Sep 2025 08:31:08 +0700 Subject: [PATCH 17/17] Apply suggestions from code review --- ydb/docs/en/core/concepts/_includes/transactions.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ydb/docs/en/core/concepts/_includes/transactions.md b/ydb/docs/en/core/concepts/_includes/transactions.md index de8148c71f6c..2236ccc3faba 100644 --- a/ydb/docs/en/core/concepts/_includes/transactions.md +++ b/ydb/docs/en/core/concepts/_includes/transactions.md @@ -26,16 +26,16 @@ If no [transaction mode](../transactions.md#modes) is specified for a query, {{ In this mode, based on the query, {{ ydb-short-name }} decides whether to execute it outside a transaction or wrap it in a transaction with *Serializable* mode. Implicit transactions are a universal way to execute queries, as they support statements of any kind with a certain behavior described below. -#### Behavior for different types of statements +#### Behavior for Different Types of Statements - **[Data Definition Language](https://en.wikipedia.org/wiki/Data_definition_language) (DDL) Statements** - DDL statements (such as [CREATE TABLE](../../yql/reference/syntax/create_table/index.md), [DROP TABLE](../../yql/reference/syntax/drop_table.md), etc.) are executed outside a transaction. A query can consist only of DDL statements. If an error occurs, changes made by previous statements in the query are not rolled back. + DDL statements (such as [`CREATE TABLE`](../../yql/reference/syntax/create_table/index.md), [`DROP TABLE`](../../yql/reference/syntax/drop_table.md), etc.) are executed outside a transaction. A query can consist only of DDL statements. If an error occurs, changes made by previous statements in the query are not rolled back. - **[Data Manipulation Language](https://en.wikipedia.org/wiki/Data_manipulation_language) (DML) Statements** - DML statements (such as [UPSERT](../../yql/reference/syntax/upsert_into.md), [SELECT](../../yql/reference/syntax/select/index.md), [UPDATE](../../yql/reference/syntax/update.md), etc.) are wrapped in a transaction with *Serializable* mode. A query can consist only of DML statements. On success, changes are committed. If an error occurs, all changes are rolled back. + DML statements (such as [`SELECT`](../../yql/reference/syntax/select/index.md), [`UPSERT`](../../yql/reference/syntax/upsert_into.md), [`UPDATE`](../../yql/reference/syntax/update.md), etc.) are wrapped in a transaction with *Serializable* mode. A query can consist only of DML statements. On success, changes are committed. If an error occurs, all changes are rolled back. - **Batch Modification Statements** - Batch modification statements (such as [BATCH UPDATE](../../yql/reference/syntax/batch-update.md) and [BATCH DELETE FROM](../../yql/reference/syntax/batch-delete.md)) are executed outside a transaction. A query can contain only one batch modification statement. If an error occurs, the statement's changes are not rolled back. + Batch modification statements (such as [`BATCH UPDATE`](../../yql/reference/syntax/batch-update.md) and [`BATCH DELETE`](../../yql/reference/syntax/batch-delete.md)) are executed outside a transaction. A query can contain only one batch modification statement. If an error occurs, the statement's changes are not rolled back. #### Summary Table