@@ -6619,7 +6619,7 @@ You can customize the client by calling the following methods:
6619
6619
* `….bindMarkers(…)`: Supply a specific `BindMarkersFactory` to configure named
6620
6620
parameter to database bind marker translation.
6621
6621
* `….executeFunction(…)`: Set the `ExecuteFunction` how `Statement` objects get
6622
- executed .
6622
+ run .
6623
6623
* `….namedParameters(false)`: Disable named parameter expansion. Enabled by default.
6624
6624
6625
6625
TIP: Dialects are resolved by {api-spring-framework}/r2dbc/core/binding/BindMarkersFactoryResolver.html[`BindMarkersFactoryResolver`]
@@ -6804,7 +6804,7 @@ input parameters. Parameterized statements bear the risk of SQL injection if
6804
6804
parameters are not escaped properly. `DatabaseClient` leverages R2DBC's
6805
6805
`bind` API to eliminate the risk of SQL injection for query parameters.
6806
6806
You can provide a parameterized SQL statement with the `execute(…)` operator
6807
- and bind parameters to the actual `Statement`. Your R2DBC driver then executes
6807
+ and bind parameters to the actual `Statement`. Your R2DBC driver then runs
6808
6808
the statement by using prepared statements and parameter substitution.
6809
6809
6810
6810
Parameter binding supports two binding strategies:
@@ -6853,7 +6853,7 @@ Consider the following query:
6853
6853
SELECT id, name, state FROM table WHERE (name, age) IN (('John', 35), ('Ann', 50))
6854
6854
----
6855
6855
6856
- The preceding query can be parametrized and executed as follows:
6856
+ The preceding query can be parametrized and run as follows:
6857
6857
6858
6858
[source,java,indent=0,subs="verbatim,quotes",role="primary"]
6859
6859
.Java
@@ -6901,7 +6901,7 @@ The following example shows a simpler variant using `IN` predicates:
6901
6901
===== Statement Filters
6902
6902
6903
6903
Sometimes it you need to fine-tune options on the actual `Statement`
6904
- before it gets executed . Register a `Statement` filter
6904
+ before it gets run . Register a `Statement` filter
6905
6905
(`StatementFilterFunction`) through `DatabaseClient` to intercept and
6906
6906
modify statements in their execution, as the following example shows:
6907
6907
@@ -6943,7 +6943,7 @@ modify statements in their execution, as the following example shows:
6943
6943
.filter { statement -> s.fetchSize(25) }
6944
6944
----
6945
6945
6946
- `StatementFilterFunction` implementations allow filtering of the executed
6946
+ `StatementFilterFunction` implementations allow filtering of the
6947
6947
`Statement` and filtering of `Result` objects.
6948
6948
6949
6949
[[r2dbc-DatabaseClient-idioms]]
@@ -7089,7 +7089,7 @@ necessarily have to know how the production data source is configured.
7089
7089
7090
7090
When you use Spring's R2DBC layer, you can can configure your own with a
7091
7091
connection pool implementation provided by a third party. A popular
7092
- implementation is R2DBC Pool (`r2dbc-pool`). Implementations in the Spring
7092
+ implementation is R2DBC Pool (`r2dbc-pool`). Implementations in the Spring
7093
7093
distribution are meant only for testing purposes and do not provide pooling.
7094
7094
7095
7095
To configure a `ConnectionFactory`:
@@ -7162,7 +7162,7 @@ javadoc for more details.
7162
7162
7163
7163
The `R2dbcTransactionManager` class is a `ReactiveTransactionManager` implementation for
7164
7164
single R2DBC datasources. It binds an R2DBC connection from the specified connection factory
7165
- to the subscriber `Context`, potentially allowing for one subscriber connection for each
7165
+ to the subscriber `Context`, potentially allowing for one subscriber connection for each
7166
7166
connection factory.
7167
7167
7168
7168
Application code is required to retrieve the R2DBC connection through
0 commit comments