6
6
#, fuzzy
7
7
msgid ""
8
8
msgstr ""
9
- "Project-Id-Version : GINO 0.5.8 \n "
9
+ "Project-Id-Version : GINO 0.7.5 \n "
10
10
"Report-Msgid-Bugs-To : \n "
11
- "POT-Creation-Date : 2018-03-07 23:28 +0800\n "
11
+ "POT-Creation-Date : 2018-08-21 12:19 +0800\n "
12
12
"PO-Revision-Date : YEAR-MO-DA HO:MI+ZONE\n "
13
13
"Language-Team : Chinese (https://www.transifex.com/decentfox-studio/teams/84194/zh/)\n "
14
14
"MIME-Version : 1.0\n "
@@ -20,170 +20,3 @@ msgstr ""
20
20
#: ../../adv_topics.rst:2
21
21
msgid "Advanced Topics"
22
22
msgstr ""
23
-
24
- #: ../../adv_topics.rst:4
25
- msgid "**THIS IS A WIP**"
26
- msgstr ""
27
-
28
- #: ../../adv_topics.rst:7
29
- msgid "Transaction and Context"
30
- msgstr ""
31
-
32
- #: ../../adv_topics.rst:9
33
- msgid ""
34
- "In normal cases when ``db`` is bound to a pool, you can start a transaction "
35
- "through ``db`` directly:"
36
- msgstr ""
37
-
38
- #: ../../adv_topics.rst:17
39
- msgid ""
40
- "As you can see from the unpacked arguments, ``db.transaction()`` acquired a "
41
- "connection and started a transaction in one go. It is identical to do it "
42
- "separately:"
43
- msgstr ""
44
-
45
- #: ../../adv_topics.rst:27
46
- msgid ""
47
- "There is an alternative to do this without ``async with``, but this may be "
48
- "changed in next version, as discussed in #59. Also, ``tx`` is always "
49
- "``None`` for now."
50
- msgstr ""
51
-
52
- #: ../../adv_topics.rst:31
53
- msgid ""
54
- "Because GINO offers query APIs on not only connections but also model "
55
- "classes and objects and even query objects, it would be too much trouble "
56
- "passing connection object around when dealing with transactions. Therefore "
57
- "GINO offers an optional feature to automatically manage connection objects, "
58
- "by enabling a builtin task local hack before any tasks are created:"
59
- msgstr ""
60
-
61
- #: ../../adv_topics.rst:42
62
- msgid ""
63
- "This switch creates a local storage for each coroutine, where "
64
- "``db.acquire()`` shall store the connection object. Hence executions within "
65
- "the acquire context will be able to make use of the same connection right in"
66
- " the local storage. Furthermore, nested ``db.acquire()`` will simply return "
67
- "the same connection. This allows ``db.transaction()`` to be nested in the "
68
- "same way that asyncpg ``conn.transaction()`` does it - to use database save "
69
- "points."
70
- msgstr ""
71
-
72
- #: ../../adv_topics.rst:55
73
- msgid ""
74
- "If nested transactions or reused connections are not expected, you can "
75
- "explicitly use ``db.acquire(reuse=False)`` or "
76
- "``db.transaction(reuse=False)`` to borrow new connections from the pool. "
77
- "Non-reused connections are stacked, they will be returned to the pool in the"
78
- " reversed order as they were borrowed. Local storage covers between "
79
- "different tasks that are awaited in a chain, it is theoretically safe in "
80
- "most cases. However it is still some sort of a hack, but it would be like "
81
- "this before Python officially supports task local storage in PEP 550."
82
- msgstr ""
83
-
84
- #: ../../adv_topics.rst:66
85
- msgid "Sanic Support"
86
- msgstr ""
87
-
88
- #: ../../adv_topics.rst:68
89
- msgid ""
90
- "To integrate with Sanic_, a few configurations needs to be set in "
91
- "``app.config`` (with default value though):"
92
- msgstr ""
93
-
94
- #: ../../adv_topics.rst:71
95
- msgid "DB_HOST: if not set, ``localhost``"
96
- msgstr ""
97
-
98
- #: ../../adv_topics.rst:72
99
- msgid "DB_PORT: if not set, ``5432``"
100
- msgstr ""
101
-
102
- #: ../../adv_topics.rst:73
103
- msgid "DB_USER: if not set, ``postgres``"
104
- msgstr ""
105
-
106
- #: ../../adv_topics.rst:74
107
- msgid "DB_PASSWORD: if not set, empty string"
108
- msgstr ""
109
-
110
- #: ../../adv_topics.rst:75
111
- msgid "DB_DATABASE: if not set, ``postgres``"
112
- msgstr ""
113
-
114
- #: ../../adv_topics.rst:76
115
- msgid "DB_POOL_MIN_SIZE: if not set, 5"
116
- msgstr ""
117
-
118
- #: ../../adv_topics.rst:77
119
- msgid "DB_POOL_MAX_SIZE: if not set, 10"
120
- msgstr ""
121
-
122
- #: ../../adv_topics.rst:79
123
- msgid "An example:"
124
- msgstr ""
125
-
126
- #: ../../adv_topics.rst:94
127
- msgid ""
128
- "After ``db.init_app``, a connection pool with configured settings shall be "
129
- "created and bound to ``db`` when Sanic server is started, and closed on "
130
- "stop. Furthermore, a lazy connection context is created on each request, and"
131
- " released on response. That is to say, within Sanic request handlers, you "
132
- "can directly access db by e.g. ``User.get(1)``, everything else is settled: "
133
- "database pool is created on server start, connection is lazily borrowed from"
134
- " pool on the first database access and shared within the rest of the same "
135
- "request handler, and automatically returned to the pool on response."
136
- msgstr ""
137
-
138
- #: ../../adv_topics.rst:103
139
- msgid ""
140
- "Please be noted that, in the async world, ``await`` may block unpredictably "
141
- "for a long time. When this world is crossing RDBMS pools and transactions, "
142
- "it is a very dangerous bite for performance, even causing disasters "
143
- "sometimes. Therefore we recommend, during the time enjoying fast "
144
- "development, do pay special attention to the scope of transactions and "
145
- "borrowed connections, make sure that transactions are closed as soon as "
146
- "possible, and connections are not taken for unnecessarily long time. As for "
147
- "the Sanic support, if you want to release the concrete connection in the "
148
- "request context before response is reached, just do it like this:"
149
- msgstr ""
150
-
151
- #: ../../adv_topics.rst:118
152
- msgid ""
153
- "Or if you prefer not to use the contextual lazy connection in certain "
154
- "handlers, prefer explicitly manage the connection lifetime, you can always "
155
- "borrow a new connection by setting ``reuse=False``:"
156
- msgstr ""
157
-
158
- #: ../../adv_topics.rst:128
159
- msgid ""
160
- "Or if you prefer not to use the builtin request-scoped lazy connection at "
161
- "all, you can simply turn it off:"
162
- msgstr ""
163
-
164
- #: ../../adv_topics.rst:137
165
- msgid "JSON Property"
166
- msgstr ""
167
-
168
- #: ../../adv_topics.rst:139
169
- msgid ""
170
- "PostgreSQL started to support native JSON type since 9.2, and became more "
171
- "feature complete in 9.4. JSON is ideal to store varying key-value data. GINO"
172
- " offers objective support for this scenario, requiring PostgreSQL 9.5 for "
173
- "now."
174
- msgstr ""
175
-
176
- #: ../../adv_topics.rst:157
177
- msgid ""
178
- "``nickname`` and ``age`` look just like normal columns, but they are "
179
- "actually key-value pairs in the ``profile`` column. ``profile`` is the "
180
- "default column name for JSON properties, you can specify a different name by"
181
- " offering the argument ``column_name`` when defining a JSON property. "
182
- "Actually multiple JSON columns are allowed, storing different JSON "
183
- "properties as needed. Also, both ``JSON`` and ``JSONB`` can be used, "
184
- "depending on your choice. For example:"
185
- msgstr ""
186
-
187
- #: ../../adv_topics.rst:183
188
- msgid "JSON properties work like normal columns too:"
189
- msgstr ""
0 commit comments