Skip to content

Commit 0328cb3

Browse files
committed
Remove slop
1 parent 0815f05 commit 0328cb3

File tree

1 file changed

+1
-59
lines changed

1 file changed

+1
-59
lines changed

docs/pages/features/transactions.mdx

Lines changed: 1 addition & 59 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ PostgreSQL transactions ensure that a series of database operations either all s
88

99
## pg-transaction Module
1010

11-
The `pg-transaction` module provides a tiny level of abstraction for handling transactions, automatically managing `BEGIN`, `COMMIT`, and `ROLLBACK` operations while ensuring proper client lifecycle management.
11+
The `pg-transaction` module provides a tiny level of abstraction for handling transactions, automatically running `BEGIN`, `COMMIT`, and/or `ROLLBACK`.
1212

1313
The motivation for this module was I pretty much write the same exact thing in every project I start. Sounds like a good thing to just publish widely.
1414

@@ -166,18 +166,6 @@ try {
166166
}
167167
```
168168

169-
### Best Practices
170-
171-
1. **Use with Pools**: When possible, use the transaction function with a `Pool` rather than a `Client` for better resource management.
172-
173-
2. **Keep Transactions Short**: Minimize the time spent in transactions to reduce lock contention.
174-
175-
3. **Handle Errors Appropriately**: Let the transaction function handle rollbacks, but ensure your application logic handles the errors appropriately.
176-
177-
4. **Avoid Nested Transactions**: PostgreSQL doesn't support true nested transactions. Use savepoints if you need nested behavior.
178-
179-
5. **Return Values**: Use the callback's return value to pass data out of the transaction.
180-
181169
### Migration from Manual Transactions
182170

183171
If you're currently using manual transaction handling, migrating to `pg-transaction` is straightforward:
@@ -244,49 +232,3 @@ try {
244232
client.release()
245233
}
246234
```
247-
248-
### When to Use Manual Transactions
249-
250-
Consider manual transaction handling when you need:
251-
252-
- **Savepoints**: Creating intermediate rollback points within a transaction
253-
- **Custom Transaction Isolation Levels**: Setting specific isolation levels
254-
- **Complex Transaction Logic**: Conditional commits or rollbacks based on business logic
255-
- **Performance Optimization**: Fine-grained control over transaction boundaries
256-
257-
### Savepoints Example
258-
259-
```js
260-
const client = await pool.connect()
261-
262-
try {
263-
await client.query('BEGIN')
264-
265-
// First operation
266-
await client.query('INSERT INTO orders(user_id, total) VALUES($1, $2)', [userId, total])
267-
268-
// Create a savepoint
269-
await client.query('SAVEPOINT order_items')
270-
271-
try {
272-
// Attempt to insert order items
273-
for (const item of items) {
274-
await client.query('INSERT INTO order_items(order_id, product_id, quantity) VALUES($1, $2, $3)',
275-
[orderId, item.productId, item.quantity])
276-
}
277-
} catch (error) {
278-
// Rollback to savepoint, keeping the order
279-
await client.query('ROLLBACK TO SAVEPOINT order_items')
280-
console.log('Order items failed, but order preserved')
281-
}
282-
283-
await client.query('COMMIT')
284-
} catch (error) {
285-
await client.query('ROLLBACK')
286-
throw error
287-
} finally {
288-
client.release()
289-
}
290-
```
291-
292-
**Recommendation**: Use `pg-transaction` for most use cases, and fall back to manual transaction handling only when you need advanced features like savepoints or custom isolation levels. Note: the number of times I've done this in production apps is _nearly_ zero.

0 commit comments

Comments
 (0)