You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
5.[Retry helpers for `YDB``database/sql` driver](#retry)
16
-
*[Over `sql.Conn` object](#retry-conn)
17
-
*[Over `sql.Tx`](#retry-tx)
18
-
6.[Query args types](#arg-types)
19
-
7.[Get native driver from `*sql.DB`](#unwrap)
17
+
5.[Changing the transaction control mode](#tx-control)
18
+
6.[Retry helpers for `YDB``database/sql` driver](#retry)
19
+
*[Retries over `sql.Conn` object](#retry-conn)
20
+
*[Retries over `sql.Tx`](#retry-tx)
21
+
7.[Specifying query parameters](#arg-types)
22
+
8.[Accessing the native driver from `*sql.DB`](#unwrap)
20
23
21
24
## Initialization of `database/sql` driver <aname="init"></a>
22
25
@@ -43,7 +46,8 @@ func main() {
43
46
db:= sql.OpenDB(connector)
44
47
}
45
48
```
46
-
### Configure driver only with data source name (connection string) <aname="init-dsn"></a>
49
+
50
+
### Configure driver with data source name or connection string <aname="init-dsn"></a>
47
51
```go
48
52
import (
49
53
_ "github.com/ydb-platform/ydb-go-sdk/v3"
@@ -58,23 +62,24 @@ Data source name parameters:
58
62
* static credentials with authority part of URI, like `grpcs://root:password@localhost:2135/local`
59
63
*`query_mode=scripting` - you can redefine default [DML](https://en.wikipedia.org/wiki/Data_manipulation_language) query mode
60
64
61
-
## About session pool <aname="session-pool"></a>
65
+
## Session pooling <aname="session-pool"></a>
62
66
63
-
Native driver `ydb-go-sdk/v3` implements internal session pool, which uses with `db.Table().Do()` or `db.Table().DoTx()` methods.
64
-
Internal session pool configures with options like `ydb.WithSessionPoolSizeLimit()` and other.
65
-
Unlike session pool in native driver, `database/sql` contains another session pool, which configures with `*sql.DB.SetMaxOpenConns` and `*sql.DB.SetMaxIdleConns`.
66
-
Lifetime of `YDB` session depends on driver configuration and predefined errors, such as `sql.driver.ErrBadConn`.
67
-
`YDB` driver for `database/sql` transform internal `YDB` errors into `sql.driver.ErrBadConn` depending on result of internal error check (delete session on error or not and other).
68
-
In most cases this behaviour of `database/sql` driver implementation for specific RDBMS completes queries without result errors.
69
-
But some errors on unfortunate cases may be get on client-side.
70
-
That's why querying must be wrapped with retry helpers, such as `retry.Do` or `retry.DoTx` (see more about retry helpers in [retry section](#retry)).
67
+
Native driver `ydb-go-sdk/v3` implements the internal session pool, which uses with `db.Table().Do()` or `db.Table().DoTx()` methods.
68
+
Internal session pool is configured with options like `ydb.WithSessionPoolSizeLimit()` and other.
69
+
Unlike the session pool in the native driver, `database/sql` contains a different implementation of the session pool, which is configured with `*sql.DB.SetMaxOpenConns` and `*sql.DB.SetMaxIdleConns`.
70
+
Lifetime of a `YDB` session depends on driver configuration and error occurance, such as `sql.driver.ErrBadConn`.
71
+
`YDB` driver for `database/sql` includes the logic to transform the internal `YDB` error codes into `sql.driver.ErrBadConn` and other retryable and non-retryable error types.
71
72
72
-
## Execute queries <aname="queries"></a>
73
+
In most cases the implementation of `database/sql` driver for YDB allows to complete queries without user-visible errors.
74
+
But some errors need to be handled on the client side, by re-running not a single operation, but a complete transaction.
75
+
Therefore the transaction logic needs to be wrapped with retry helpers, such as `retry.Do` or `retry.DoTx` (see more about retry helpers in the [retry section](#retry)).
73
76
74
-
### On database object <aname="queries-db"></a>
77
+
## Query execution <aname="queries"></a>
78
+
79
+
### Queries on database object <aname="queries-db"></a>
75
80
```go
76
81
rows, err:= db.QueryContext(ctx,
77
-
"SELECT series_id, title, release_date FROM /full/path/of/table/series;"
82
+
"SELECT series_id, title, release_date FROM `/full/path/of/table/series`;"
78
83
)
79
84
if err != nil {
80
85
log.Fatal(err)
@@ -97,19 +102,23 @@ if err = rows.Err(); err != nil { // always check final rows err
97
102
}
98
103
```
99
104
100
-
### With transaction <aname="queries-tx"></a>
101
-
Supports only `default` transaction options which mapped to `YDB``SerializableReadWrite` transaction settings.
105
+
### Queries on transaction object <aname="queries-tx"></a>
106
+
Query execution on transaction object supports only `default` transaction options
107
+
which are mapped to `YDB``SerializableReadWrite` transaction settings.
108
+
109
+
`YDB`'s `OnlineReadOnly` and `StaleReadOnly` transaction settings are not compatible
110
+
with interactive transactions such as `database/sql`'s `*sql.Tx`.
111
+
That's why `ydb-go-sdk` implements read-only `sql.LevelSnapshot` with fake transaction
112
+
(temporary, until `YDB` starts to support true snapshot isolation mode).
102
113
103
-
`YDB`'s `OnlineReadOnly` and `StaleReadOnly` transaction settings are not compatible with interactive transactions such as `database/sql`'s `*sql.Tx`.
104
-
That's why `ydb-go-sdk` implements read-only `sql.LevelSnapshot` with fake transaction (temporary, while `YDB` main clusters are supports true snapshot isolation mode)
105
114
```go
106
115
tx, err:= db.BeginTx(ctx, sql.TxOptions{})
107
116
if err != nil {
108
117
log.Fatal(err)
109
118
}
110
119
defer tx.Rollback()
111
120
rows, err:= tx.QueryContext(ctx,
112
-
"SELECT series_id, title, release_date FROM /full/path/of/table/series;"
121
+
"SELECT series_id, title, release_date FROM `/full/path/of/table/series`;"
The `YDB` server API is currently requires to select a specific method by specific request type. For example, [DDL](https://en.wikipedia.org/wiki/Data_definition_language) must be called with `table.session.ExecuteSchemeQuery`, [DML](https://en.wikipedia.org/wiki/Data_manipulation_language) must be called with `table.session.Execute`, [DQL](https://en.wikipedia.org/wiki/Data_query_language) may be called with `table.session.Execute` or `table.session.StreamExecuteScanQuery` etc. `YDB` have a `scripting` service also, which provides different query types with single method, but not supports transactions.
148
+
Currently the `YDB` server APIs require the use of a proper GRPC service method depending on the specific request type.
149
+
In particular, [DDL](https://en.wikipedia.org/wiki/Data_definition_language) must be called through `table.session.ExecuteSchemeQuery`,
150
+
[DML](https://en.wikipedia.org/wiki/Data_manipulation_language) needs `table.session.Execute`, and
151
+
[DQL](https://en.wikipedia.org/wiki/Data_query_language) should be passed via `table.session.Execute` or `table.session.StreamExecuteScanQuery`.
152
+
`YDB` also has a so-called "scripting" service, which supports different query types within a single method,
153
+
but without support for transactions.
139
154
140
-
That's why needs to select query mode on client side currently.
155
+
Unfortunately, this leads to the need to choose the proper query mode on the application side.
141
156
142
-
`YDB` team have a roadmap goal to implements a single method for executing different query types.
157
+
`YDB` team has a roadmap goal to implement a single universal service method for executing
158
+
different query types and without the limitations of the "scripting" service method.
143
159
144
-
`database/sql` driver implementation for `YDB` supports next query modes:
160
+
`database/sql` driver implementation for `YDB` supports the following query modes:
145
161
*`ydb.DataQueryMode` - default query mode, for lookup [DQL](https://en.wikipedia.org/wiki/Data_query_language) queries and [DML](https://en.wikipedia.org/wiki/Data_manipulation_language) queries.
146
-
*`ydb.ExplainQueryMode` - for gettting plan and [AST](https://en.wikipedia.org/wiki/Abstract_syntax_tree) of some query
147
-
*`ydb.ScanQueryMode` - for strong[OLAP](https://en.wikipedia.org/wiki/Online_analytical_processing) scenarious, [DQL-only](https://en.wikipedia.org/wiki/Data_query_language) queries. Read more about scan queries in [ydb.tech](https://ydb.tech/en/docs/concepts/scan_query)
162
+
*`ydb.ExplainQueryMode` - for gettting plan and [AST](https://en.wikipedia.org/wiki/Abstract_syntax_tree) of the query
163
+
*`ydb.ScanQueryMode` - for heavy[OLAP](https://en.wikipedia.org/wiki/Online_analytical_processing)style scenarious, with[DQL-only](https://en.wikipedia.org/wiki/Data_query_language) queries. Read more about scan queries in [ydb.tech](https://ydb.tech/en/docs/concepts/scan_query)
148
164
*`ydb.SchemeQueryMode` - for [DDL](https://en.wikipedia.org/wiki/Data_definition_language) queries
149
-
*`ydb.ScriptingQueryMode` - for [DDL](https://en.wikipedia.org/wiki/Data_definition_language), [DML](https://en.wikipedia.org/wiki/Data_manipulation_language), [DQL](https://en.wikipedia.org/wiki/Data_query_language) queries (not a [TCL](https://en.wikipedia.org/wiki/SQL#Transaction_controls)). Be careful: queries executes longer than with other query modes and consumes bigger server-side resources
165
+
*`ydb.ScriptingQueryMode` - for [DDL](https://en.wikipedia.org/wiki/Data_definition_language), [DML](https://en.wikipedia.org/wiki/Data_manipulation_language), [DQL](https://en.wikipedia.org/wiki/Data_query_language) queries (not a [TCL](https://en.wikipedia.org/wiki/SQL#Transaction_controls)). Be careful: queries execute longer than with other query modes, and consume more server-side resources
0 commit comments