@@ -132,9 +132,9 @@ of search parameters such as the following:
132
132
#### Password encoding
133
133
134
134
One thing that must be taken into consideration is that passwords contained
135
- inside the URL must be properly encoded to be passed down to the
136
- database. You can achieve that by using the JavaScript API ` encodeURIComponent `
137
- and passing your password as an argument.
135
+ inside the URL must be properly encoded to be passed down to the database. You
136
+ can achieve that by using the JavaScript API ` encodeURIComponent ` and passing
137
+ your password as an argument.
138
138
139
139
** Invalid** :
140
140
@@ -147,8 +147,8 @@ and passing your password as an argument.
147
147
- ` postgres://me:p%C3%A1ssword!%3Dwith_symbols@localhost:5432/my_database `
148
148
149
149
If the password is not encoded correctly, the driver will try to pass the raw
150
- password to the database, however, it's highly recommended that all passwords are
151
- always encoded to prevent authentication errors
150
+ password to the database, however, it's highly recommended that all passwords
151
+ are always encoded to prevent authentication errors
152
152
153
153
### Database reconnection
154
154
@@ -175,8 +175,8 @@ try {
175
175
await client .queryArray ` SELECT 1 ` ;
176
176
```
177
177
178
- If automatic reconnection is not desired, the developer can set the
179
- number of attempts to zero and manage connection and reconnection manually
178
+ If automatic reconnection is not desired, the developer can set the number of
179
+ attempts to zero and manage connection and reconnection manually
180
180
181
181
``` ts
182
182
const client = new Client ({
@@ -597,9 +597,9 @@ replaced at runtime with an argument object
597
597
}
598
598
```
599
599
600
- Behind the scenes, ` deno-postgres ` will replace the variable names in your
601
- query for Postgres-readable placeholders making it easy to reuse values in
602
- multiple places in your query
600
+ Behind the scenes, ` deno-postgres ` will replace the variable names in your query
601
+ for Postgres-readable placeholders making it easy to reuse values in multiple
602
+ places in your query
603
603
604
604
``` ts
605
605
{
@@ -653,11 +653,11 @@ intended
653
653
654
654
#### Regarding non-argument parameters
655
655
656
- A common assumption many people make when working with prepared statements is that
657
- they work the same way string interpolation works, by replacing the placeholders
658
- with whatever variables have been passed down to the query. However the reality
659
- is a little more complicated than that where only very specific parts of a query
660
- can use placeholders to indicate upcoming values
656
+ A common assumption many people make when working with prepared statements is
657
+ that they work the same way string interpolation works, by replacing the
658
+ placeholders with whatever variables have been passed down to the query. However
659
+ the reality is a little more complicated than that where only very specific
660
+ parts of a query can use placeholders to indicate upcoming values
661
661
662
662
That's the reason why the following works
663
663
@@ -949,8 +949,8 @@ Other aspects to take into account when using the `fields` argument:
949
949
950
950
A lot of effort was put into abstracting Transactions in the library, and the
951
951
final result is an API that is both simple to use and offers all of the options
952
- and features that you would get by executing SQL statements, plus an extra
953
- layer of abstraction that helps you catch mistakes ahead of time.
952
+ and features that you would get by executing SQL statements, plus an extra layer
953
+ of abstraction that helps you catch mistakes ahead of time.
954
954
955
955
#### Creating a transaction
956
956
@@ -977,8 +977,8 @@ Due to how SQL transactions work, every time you begin a transaction all queries
977
977
you do in your session will run inside that transaction context. This is a
978
978
problem for query execution since it might cause queries that are meant to do
979
979
persistent changes to the database to live inside this context, making them
980
- susceptible to being rolled back unintentionally. We will call this kind of queries
981
- ** unsafe operations** .
980
+ susceptible to being rolled back unintentionally. We will call this kind of
981
+ queries ** unsafe operations** .
982
982
983
983
Every time you create a transaction the client you use will get a lock, with the
984
984
purpose of blocking any external queries from running while a transaction takes
@@ -1001,9 +1001,9 @@ await client.queryArray`DELETE TABLE X`;
1001
1001
For this very reason, however, if you are using transactions in an application
1002
1002
with concurrent access like an API, it is recommended that you don't use the
1003
1003
Client API at all. If you do so, the client will be blocked from executing other
1004
- queries until the transaction has finished. Instead, use a connection
1005
- pool, that way all your operations will be executed in a different context
1006
- without locking the main client.
1004
+ queries until the transaction has finished. Instead, use a connection pool, that
1005
+ way all your operations will be executed in a different context without locking
1006
+ the main client.
1007
1007
1008
1008
``` ts
1009
1009
const client_1 = await pool .connect ();
@@ -1066,8 +1066,8 @@ function executeMyTransaction() {
1066
1066
1067
1067
This limits only to database-related errors though, regular errors won't end the
1068
1068
connection and may allow the user to execute a different code path. This is
1069
- especially good for ahead-of-time validation errors such as the ones found in the
1070
- rollback and savepoint features.
1069
+ especially good for ahead-of-time validation errors such as the ones found in
1070
+ the rollback and savepoint features.
1071
1071
1072
1072
``` ts
1073
1073
const transaction = client .createTransaction (" abortable" );
@@ -1098,8 +1098,8 @@ await transaction.commit();
1098
1098
#### Transaction options
1099
1099
1100
1100
PostgreSQL provides many options to customize the behavior of transactions, such
1101
- as isolation level, read modes, and startup snapshot. All these options can be set
1102
- by passing a second argument to the ` startTransaction ` method
1101
+ as isolation level, read modes, and startup snapshot. All these options can be
1102
+ set by passing a second argument to the ` startTransaction ` method
1103
1103
1104
1104
``` ts
1105
1105
const transaction = client .createTransaction (" ts_1" , {
@@ -1116,8 +1116,9 @@ place _after_ the transaction had begun.
1116
1116
1117
1117
The following is a demonstration. A sensible transaction that loads a table with
1118
1118
some very important test results and the students that passed said test. This is
1119
- a long-running operation, and in the meanwhile, someone is tasked to clean up the
1120
- results from the tests table because it's taking up too much space in the database.
1119
+ a long-running operation, and in the meanwhile, someone is tasked to clean up
1120
+ the results from the tests table because it's taking up too much space in the
1121
+ database.
1121
1122
1122
1123
If the transaction were to be executed as follows, the test results would be
1123
1124
lost before the graduated students could be extracted from the original table,
@@ -1357,7 +1358,8 @@ await transaction.rollback(savepoint); // Truncate gets undone
1357
1358
##### Rollback
1358
1359
1359
1360
A rollback allows the user to end the transaction without persisting the changes
1360
- made to the database, preventing that way any unwanted operation from taking place.
1361
+ made to the database, preventing that way any unwanted operation from taking
1362
+ place.
1361
1363
1362
1364
``` ts
1363
1365
const transaction = client .createTransaction (" rolled_back_transaction" );
0 commit comments