|
28 | 28 | >>> db.one("SELECT * FROM foo ORDER BY bar") |
29 | 29 | {'bar': 'baz'} |
30 | 30 | >>> db.one("SELECT * FROM foo WHERE bar='blam'") |
31 | | - None |
| 31 | + >>> # None |
32 | 32 |
|
33 | 33 | Use :py:meth:`~postgres.Postgres.rows` to fetch all results: |
34 | 34 |
|
|
62 | 62 | :py:meth:`~postgres.Postgres.rows` API introduced above. For the other 20%, |
63 | 63 | :py:mod:`postgres` provides context managers for working at increasingly lower |
64 | 64 | levels of abstraction. The lowest level of abstraction in :py:mod:`postgres` is |
65 | | -a :py:mod:`psycopg2` connection pool that we configure and manage for you. |
66 | | -Everything in :py:mod:`postgres`, both the simple API and the context managers, |
67 | | -uses this connection pool. |
| 65 | +a :py:mod:`psycopg2` `connection pool |
| 66 | +<http://initd.org/psycopg/docs/pool.html>`_ that we configure and manage for |
| 67 | +you. Everything in :py:mod:`postgres`, both the simple API and the context |
| 68 | +managers, uses this connection pool. |
68 | 69 |
|
69 | | -Here's how to work directly with a :py:mod:`psycogpg2.cursor` (`docs |
70 | | -<http://initd.org/psycopg/docs/cursor.html>`_) while still taking advantage of |
| 70 | +Here's how to work directly with a :py:mod:`psycogpg2` `cursor |
| 71 | +<http://initd.org/psycopg/docs/cursor.html>`_ while still taking advantage of |
71 | 72 | connection pooling: |
72 | 73 |
|
73 | 74 | >>> with db.get_cursor() as cursor: |
|
90 | 91 | [{'bar': 'baz'}, {'bar': 'blam'}, {'bar': 'buz'}] |
91 | 92 |
|
92 | 93 | Note that other calls won't see the changes on your transaction until the end |
93 | | -of your code block, when the context manager commits the transaction:: |
| 94 | +of your code block, when the context manager commits the transaction for you:: |
94 | 95 |
|
95 | 96 | >>> with db.get_transaction() as txn: |
96 | 97 | ... txn.execute("INSERT INTO foo VALUES ('blam')") |
|
102 | 103 |
|
103 | 104 | The :py:func:`~postgres.Postgres.get_transaction` manager gives you a cursor |
104 | 105 | with :py:attr:`autocommit` turned off on its connection. If the block under |
105 | | -management raises, the connection is rolled back. Otherwise it's committed. |
106 | | -Use this when you want a series of statements to be part of one transaction, |
107 | | -but you don't need fine-grained control over the transaction. For fine-grained |
108 | | -control, use :py:func:`~postgres.Postgres.get_connection` to get a connection |
109 | | -straight from the connection pool: |
| 106 | +management raises an exception, the connection is rolled back. Otherwise it's |
| 107 | +committed. Use this when you want a series of statements to be part of one |
| 108 | +transaction, but you don't need fine-grained control over the transaction. For |
| 109 | +fine-grained control, use :py:func:`~postgres.Postgres.get_connection` to get a |
| 110 | +connection straight from the connection pool: |
110 | 111 |
|
111 | 112 | >>> with db.get_connection() as connection: |
112 | 113 | ... cursor = connection.cursor() |
|
118 | 119 | A connection gotten in this way will have :py:attr:`autocommit` turned off, and |
119 | 120 | it'll never be implicitly committed otherwise. It'll actually be rolled back |
120 | 121 | when you're done with it, so it's up to you to explicitly commit as needed. |
| 122 | +This is the lowest-level abstraction that :py:mod:`postgres` provides, |
| 123 | +basically just a pre-configured connection pool from :py:mod:`psycopg2`. |
121 | 124 |
|
122 | 125 |
|
123 | 126 | API |
|
0 commit comments