|
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