|
1 :mod:`sqlite3` --- DB-API 2.0 interface for SQLite databases |
|
2 ============================================================ |
|
3 |
|
4 .. module:: sqlite3 |
|
5 :synopsis: A DB-API 2.0 implementation using SQLite 3.x. |
|
6 .. sectionauthor:: Gerhard Häring <gh@ghaering.de> |
|
7 |
|
8 |
|
9 .. versionadded:: 2.5 |
|
10 |
|
11 SQLite is a C library that provides a lightweight disk-based database that |
|
12 doesn't require a separate server process and allows accessing the database |
|
13 using a nonstandard variant of the SQL query language. Some applications can use |
|
14 SQLite for internal data storage. It's also possible to prototype an |
|
15 application using SQLite and then port the code to a larger database such as |
|
16 PostgreSQL or Oracle. |
|
17 |
|
18 pysqlite was written by Gerhard Häring and provides a SQL interface compliant |
|
19 with the DB-API 2.0 specification described by :pep:`249`. |
|
20 |
|
21 To use the module, you must first create a :class:`Connection` object that |
|
22 represents the database. Here the data will be stored in the |
|
23 :file:`/tmp/example` file:: |
|
24 |
|
25 conn = sqlite3.connect('/tmp/example') |
|
26 |
|
27 You can also supply the special name ``:memory:`` to create a database in RAM. |
|
28 |
|
29 Once you have a :class:`Connection`, you can create a :class:`Cursor` object |
|
30 and call its :meth:`~Cursor.execute` method to perform SQL commands:: |
|
31 |
|
32 c = conn.cursor() |
|
33 |
|
34 # Create table |
|
35 c.execute('''create table stocks |
|
36 (date text, trans text, symbol text, |
|
37 qty real, price real)''') |
|
38 |
|
39 # Insert a row of data |
|
40 c.execute("""insert into stocks |
|
41 values ('2006-01-05','BUY','RHAT',100,35.14)""") |
|
42 |
|
43 # Save (commit) the changes |
|
44 conn.commit() |
|
45 |
|
46 # We can also close the cursor if we are done with it |
|
47 c.close() |
|
48 |
|
49 Usually your SQL operations will need to use values from Python variables. You |
|
50 shouldn't assemble your query using Python's string operations because doing so |
|
51 is insecure; it makes your program vulnerable to an SQL injection attack. |
|
52 |
|
53 Instead, use the DB-API's parameter substitution. Put ``?`` as a placeholder |
|
54 wherever you want to use a value, and then provide a tuple of values as the |
|
55 second argument to the cursor's :meth:`~Cursor.execute` method. (Other database modules |
|
56 may use a different placeholder, such as ``%s`` or ``:1``.) For example:: |
|
57 |
|
58 # Never do this -- insecure! |
|
59 symbol = 'IBM' |
|
60 c.execute("... where symbol = '%s'" % symbol) |
|
61 |
|
62 # Do this instead |
|
63 t = (symbol,) |
|
64 c.execute('select * from stocks where symbol=?', t) |
|
65 |
|
66 # Larger example |
|
67 for t in [('2006-03-28', 'BUY', 'IBM', 1000, 45.00), |
|
68 ('2006-04-05', 'BUY', 'MSOFT', 1000, 72.00), |
|
69 ('2006-04-06', 'SELL', 'IBM', 500, 53.00), |
|
70 ]: |
|
71 c.execute('insert into stocks values (?,?,?,?,?)', t) |
|
72 |
|
73 To retrieve data after executing a SELECT statement, you can either treat the |
|
74 cursor as an :term:`iterator`, call the cursor's :meth:`~Cursor.fetchone` method to |
|
75 retrieve a single matching row, or call :meth:`~Cursor.fetchall` to get a list of the |
|
76 matching rows. |
|
77 |
|
78 This example uses the iterator form:: |
|
79 |
|
80 >>> c = conn.cursor() |
|
81 >>> c.execute('select * from stocks order by price') |
|
82 >>> for row in c: |
|
83 ... print row |
|
84 ... |
|
85 (u'2006-01-05', u'BUY', u'RHAT', 100, 35.140000000000001) |
|
86 (u'2006-03-28', u'BUY', u'IBM', 1000, 45.0) |
|
87 (u'2006-04-06', u'SELL', u'IBM', 500, 53.0) |
|
88 (u'2006-04-05', u'BUY', u'MSOFT', 1000, 72.0) |
|
89 >>> |
|
90 |
|
91 |
|
92 .. seealso:: |
|
93 |
|
94 http://www.pysqlite.org |
|
95 The pysqlite web page. |
|
96 |
|
97 http://www.sqlite.org |
|
98 The SQLite web page; the documentation describes the syntax and the available |
|
99 data types for the supported SQL dialect. |
|
100 |
|
101 :pep:`249` - Database API Specification 2.0 |
|
102 PEP written by Marc-André Lemburg. |
|
103 |
|
104 |
|
105 .. _sqlite3-module-contents: |
|
106 |
|
107 Module functions and constants |
|
108 ------------------------------ |
|
109 |
|
110 |
|
111 .. data:: PARSE_DECLTYPES |
|
112 |
|
113 This constant is meant to be used with the *detect_types* parameter of the |
|
114 :func:`connect` function. |
|
115 |
|
116 Setting it makes the :mod:`sqlite3` module parse the declared type for each |
|
117 column it returns. It will parse out the first word of the declared type, |
|
118 i. e. for "integer primary key", it will parse out "integer", or for |
|
119 "number(10)" it will parse out "number". Then for that column, it will look |
|
120 into the converters dictionary and use the converter function registered for |
|
121 that type there. |
|
122 |
|
123 |
|
124 .. data:: PARSE_COLNAMES |
|
125 |
|
126 This constant is meant to be used with the *detect_types* parameter of the |
|
127 :func:`connect` function. |
|
128 |
|
129 Setting this makes the SQLite interface parse the column name for each column it |
|
130 returns. It will look for a string formed [mytype] in there, and then decide |
|
131 that 'mytype' is the type of the column. It will try to find an entry of |
|
132 'mytype' in the converters dictionary and then use the converter function found |
|
133 there to return the value. The column name found in :attr:`Cursor.description` |
|
134 is only the first word of the column name, i. e. if you use something like |
|
135 ``'as "x [datetime]"'`` in your SQL, then we will parse out everything until the |
|
136 first blank for the column name: the column name would simply be "x". |
|
137 |
|
138 |
|
139 .. function:: connect(database[, timeout, isolation_level, detect_types, factory]) |
|
140 |
|
141 Opens a connection to the SQLite database file *database*. You can use |
|
142 ``":memory:"`` to open a database connection to a database that resides in RAM |
|
143 instead of on disk. |
|
144 |
|
145 When a database is accessed by multiple connections, and one of the processes |
|
146 modifies the database, the SQLite database is locked until that transaction is |
|
147 committed. The *timeout* parameter specifies how long the connection should wait |
|
148 for the lock to go away until raising an exception. The default for the timeout |
|
149 parameter is 5.0 (five seconds). |
|
150 |
|
151 For the *isolation_level* parameter, please see the |
|
152 :attr:`Connection.isolation_level` property of :class:`Connection` objects. |
|
153 |
|
154 SQLite natively supports only the types TEXT, INTEGER, FLOAT, BLOB and NULL. If |
|
155 you want to use other types you must add support for them yourself. The |
|
156 *detect_types* parameter and the using custom **converters** registered with the |
|
157 module-level :func:`register_converter` function allow you to easily do that. |
|
158 |
|
159 *detect_types* defaults to 0 (i. e. off, no type detection), you can set it to |
|
160 any combination of :const:`PARSE_DECLTYPES` and :const:`PARSE_COLNAMES` to turn |
|
161 type detection on. |
|
162 |
|
163 By default, the :mod:`sqlite3` module uses its :class:`Connection` class for the |
|
164 connect call. You can, however, subclass the :class:`Connection` class and make |
|
165 :func:`connect` use your class instead by providing your class for the *factory* |
|
166 parameter. |
|
167 |
|
168 Consult the section :ref:`sqlite3-types` of this manual for details. |
|
169 |
|
170 The :mod:`sqlite3` module internally uses a statement cache to avoid SQL parsing |
|
171 overhead. If you want to explicitly set the number of statements that are cached |
|
172 for the connection, you can set the *cached_statements* parameter. The currently |
|
173 implemented default is to cache 100 statements. |
|
174 |
|
175 |
|
176 .. function:: register_converter(typename, callable) |
|
177 |
|
178 Registers a callable to convert a bytestring from the database into a custom |
|
179 Python type. The callable will be invoked for all database values that are of |
|
180 the type *typename*. Confer the parameter *detect_types* of the :func:`connect` |
|
181 function for how the type detection works. Note that the case of *typename* and |
|
182 the name of the type in your query must match! |
|
183 |
|
184 |
|
185 .. function:: register_adapter(type, callable) |
|
186 |
|
187 Registers a callable to convert the custom Python type *type* into one of |
|
188 SQLite's supported types. The callable *callable* accepts as single parameter |
|
189 the Python value, and must return a value of the following types: int, long, |
|
190 float, str (UTF-8 encoded), unicode or buffer. |
|
191 |
|
192 |
|
193 .. function:: complete_statement(sql) |
|
194 |
|
195 Returns :const:`True` if the string *sql* contains one or more complete SQL |
|
196 statements terminated by semicolons. It does not verify that the SQL is |
|
197 syntactically correct, only that there are no unclosed string literals and the |
|
198 statement is terminated by a semicolon. |
|
199 |
|
200 This can be used to build a shell for SQLite, as in the following example: |
|
201 |
|
202 |
|
203 .. literalinclude:: ../includes/sqlite3/complete_statement.py |
|
204 |
|
205 |
|
206 .. function:: enable_callback_tracebacks(flag) |
|
207 |
|
208 By default you will not get any tracebacks in user-defined functions, |
|
209 aggregates, converters, authorizer callbacks etc. If you want to debug them, you |
|
210 can call this function with *flag* as True. Afterwards, you will get tracebacks |
|
211 from callbacks on ``sys.stderr``. Use :const:`False` to disable the feature |
|
212 again. |
|
213 |
|
214 |
|
215 .. _sqlite3-connection-objects: |
|
216 |
|
217 Connection Objects |
|
218 ------------------ |
|
219 |
|
220 .. class:: Connection |
|
221 |
|
222 A SQLite database connection has the following attributes and methods: |
|
223 |
|
224 .. attribute:: Connection.isolation_level |
|
225 |
|
226 Get or set the current isolation level. :const:`None` for autocommit mode or one of |
|
227 "DEFERRED", "IMMEDIATE" or "EXLUSIVE". See section |
|
228 :ref:`sqlite3-controlling-transactions` for a more detailed explanation. |
|
229 |
|
230 |
|
231 .. method:: Connection.cursor([cursorClass]) |
|
232 |
|
233 The cursor method accepts a single optional parameter *cursorClass*. If |
|
234 supplied, this must be a custom cursor class that extends |
|
235 :class:`sqlite3.Cursor`. |
|
236 |
|
237 |
|
238 .. method:: Connection.commit() |
|
239 |
|
240 This method commits the current transaction. If you don't call this method, |
|
241 anything you did since the last call to ``commit()`` is not visible from from |
|
242 other database connections. If you wonder why you don't see the data you've |
|
243 written to the database, please check you didn't forget to call this method. |
|
244 |
|
245 .. method:: Connection.rollback() |
|
246 |
|
247 This method rolls back any changes to the database since the last call to |
|
248 :meth:`commit`. |
|
249 |
|
250 .. method:: Connection.close() |
|
251 |
|
252 This closes the database connection. Note that this does not automatically |
|
253 call :meth:`commit`. If you just close your database connection without |
|
254 calling :meth:`commit` first, your changes will be lost! |
|
255 |
|
256 .. method:: Connection.execute(sql, [parameters]) |
|
257 |
|
258 This is a nonstandard shortcut that creates an intermediate cursor object by |
|
259 calling the cursor method, then calls the cursor's :meth:`execute` method with |
|
260 the parameters given. |
|
261 |
|
262 |
|
263 .. method:: Connection.executemany(sql, [parameters]) |
|
264 |
|
265 This is a nonstandard shortcut that creates an intermediate cursor object by |
|
266 calling the cursor method, then calls the cursor's :meth:`executemany` method |
|
267 with the parameters given. |
|
268 |
|
269 .. method:: Connection.executescript(sql_script) |
|
270 |
|
271 This is a nonstandard shortcut that creates an intermediate cursor object by |
|
272 calling the cursor method, then calls the cursor's :meth:`executescript` method |
|
273 with the parameters given. |
|
274 |
|
275 |
|
276 .. method:: Connection.create_function(name, num_params, func) |
|
277 |
|
278 Creates a user-defined function that you can later use from within SQL |
|
279 statements under the function name *name*. *num_params* is the number of |
|
280 parameters the function accepts, and *func* is a Python callable that is called |
|
281 as the SQL function. |
|
282 |
|
283 The function can return any of the types supported by SQLite: unicode, str, int, |
|
284 long, float, buffer and None. |
|
285 |
|
286 Example: |
|
287 |
|
288 .. literalinclude:: ../includes/sqlite3/md5func.py |
|
289 |
|
290 |
|
291 .. method:: Connection.create_aggregate(name, num_params, aggregate_class) |
|
292 |
|
293 Creates a user-defined aggregate function. |
|
294 |
|
295 The aggregate class must implement a ``step`` method, which accepts the number |
|
296 of parameters *num_params*, and a ``finalize`` method which will return the |
|
297 final result of the aggregate. |
|
298 |
|
299 The ``finalize`` method can return any of the types supported by SQLite: |
|
300 unicode, str, int, long, float, buffer and None. |
|
301 |
|
302 Example: |
|
303 |
|
304 .. literalinclude:: ../includes/sqlite3/mysumaggr.py |
|
305 |
|
306 |
|
307 .. method:: Connection.create_collation(name, callable) |
|
308 |
|
309 Creates a collation with the specified *name* and *callable*. The callable will |
|
310 be passed two string arguments. It should return -1 if the first is ordered |
|
311 lower than the second, 0 if they are ordered equal and 1 if the first is ordered |
|
312 higher than the second. Note that this controls sorting (ORDER BY in SQL) so |
|
313 your comparisons don't affect other SQL operations. |
|
314 |
|
315 Note that the callable will get its parameters as Python bytestrings, which will |
|
316 normally be encoded in UTF-8. |
|
317 |
|
318 The following example shows a custom collation that sorts "the wrong way": |
|
319 |
|
320 .. literalinclude:: ../includes/sqlite3/collation_reverse.py |
|
321 |
|
322 To remove a collation, call ``create_collation`` with None as callable:: |
|
323 |
|
324 con.create_collation("reverse", None) |
|
325 |
|
326 |
|
327 .. method:: Connection.interrupt() |
|
328 |
|
329 You can call this method from a different thread to abort any queries that might |
|
330 be executing on the connection. The query will then abort and the caller will |
|
331 get an exception. |
|
332 |
|
333 |
|
334 .. method:: Connection.set_authorizer(authorizer_callback) |
|
335 |
|
336 This routine registers a callback. The callback is invoked for each attempt to |
|
337 access a column of a table in the database. The callback should return |
|
338 :const:`SQLITE_OK` if access is allowed, :const:`SQLITE_DENY` if the entire SQL |
|
339 statement should be aborted with an error and :const:`SQLITE_IGNORE` if the |
|
340 column should be treated as a NULL value. These constants are available in the |
|
341 :mod:`sqlite3` module. |
|
342 |
|
343 The first argument to the callback signifies what kind of operation is to be |
|
344 authorized. The second and third argument will be arguments or :const:`None` |
|
345 depending on the first argument. The 4th argument is the name of the database |
|
346 ("main", "temp", etc.) if applicable. The 5th argument is the name of the |
|
347 inner-most trigger or view that is responsible for the access attempt or |
|
348 :const:`None` if this access attempt is directly from input SQL code. |
|
349 |
|
350 Please consult the SQLite documentation about the possible values for the first |
|
351 argument and the meaning of the second and third argument depending on the first |
|
352 one. All necessary constants are available in the :mod:`sqlite3` module. |
|
353 |
|
354 |
|
355 .. method:: Connection.set_progress_handler(handler, n) |
|
356 |
|
357 .. versionadded:: 2.6 |
|
358 |
|
359 This routine registers a callback. The callback is invoked for every *n* |
|
360 instructions of the SQLite virtual machine. This is useful if you want to |
|
361 get called from SQLite during long-running operations, for example to update |
|
362 a GUI. |
|
363 |
|
364 If you want to clear any previously installed progress handler, call the |
|
365 method with :const:`None` for *handler*. |
|
366 |
|
367 |
|
368 .. attribute:: Connection.row_factory |
|
369 |
|
370 You can change this attribute to a callable that accepts the cursor and the |
|
371 original row as a tuple and will return the real result row. This way, you can |
|
372 implement more advanced ways of returning results, such as returning an object |
|
373 that can also access columns by name. |
|
374 |
|
375 Example: |
|
376 |
|
377 .. literalinclude:: ../includes/sqlite3/row_factory.py |
|
378 |
|
379 If returning a tuple doesn't suffice and you want name-based access to |
|
380 columns, you should consider setting :attr:`row_factory` to the |
|
381 highly-optimized :class:`sqlite3.Row` type. :class:`Row` provides both |
|
382 index-based and case-insensitive name-based access to columns with almost no |
|
383 memory overhead. It will probably be better than your own custom |
|
384 dictionary-based approach or even a db_row based solution. |
|
385 |
|
386 .. XXX what's a db_row-based solution? |
|
387 |
|
388 |
|
389 .. attribute:: Connection.text_factory |
|
390 |
|
391 Using this attribute you can control what objects are returned for the ``TEXT`` |
|
392 data type. By default, this attribute is set to :class:`unicode` and the |
|
393 :mod:`sqlite3` module will return Unicode objects for ``TEXT``. If you want to |
|
394 return bytestrings instead, you can set it to :class:`str`. |
|
395 |
|
396 For efficiency reasons, there's also a way to return Unicode objects only for |
|
397 non-ASCII data, and bytestrings otherwise. To activate it, set this attribute to |
|
398 :const:`sqlite3.OptimizedUnicode`. |
|
399 |
|
400 You can also set it to any other callable that accepts a single bytestring |
|
401 parameter and returns the resulting object. |
|
402 |
|
403 See the following example code for illustration: |
|
404 |
|
405 .. literalinclude:: ../includes/sqlite3/text_factory.py |
|
406 |
|
407 |
|
408 .. attribute:: Connection.total_changes |
|
409 |
|
410 Returns the total number of database rows that have been modified, inserted, or |
|
411 deleted since the database connection was opened. |
|
412 |
|
413 |
|
414 .. attribute:: Connection.iterdump |
|
415 |
|
416 Returns an iterator to dump the database in an SQL text format. Useful when |
|
417 saving an in-memory database for later restoration. This function provides |
|
418 the same capabilities as the :kbd:`.dump` command in the :program:`sqlite3` |
|
419 shell. |
|
420 |
|
421 .. versionadded:: 2.6 |
|
422 |
|
423 Example:: |
|
424 |
|
425 # Convert file existing_db.db to SQL dump file dump.sql |
|
426 import sqlite3, os |
|
427 |
|
428 con = sqlite3.connect('existing_db.db') |
|
429 with open('dump.sql', 'w') as f: |
|
430 for line in con.iterdump(): |
|
431 f.write('%s\n' % line) |
|
432 |
|
433 |
|
434 .. _sqlite3-cursor-objects: |
|
435 |
|
436 Cursor Objects |
|
437 -------------- |
|
438 |
|
439 .. class:: Cursor |
|
440 |
|
441 A SQLite database cursor has the following attributes and methods: |
|
442 |
|
443 .. method:: Cursor.execute(sql, [parameters]) |
|
444 |
|
445 Executes an SQL statement. The SQL statement may be parametrized (i. e. |
|
446 placeholders instead of SQL literals). The :mod:`sqlite3` module supports two |
|
447 kinds of placeholders: question marks (qmark style) and named placeholders |
|
448 (named style). |
|
449 |
|
450 This example shows how to use parameters with qmark style: |
|
451 |
|
452 .. literalinclude:: ../includes/sqlite3/execute_1.py |
|
453 |
|
454 This example shows how to use the named style: |
|
455 |
|
456 .. literalinclude:: ../includes/sqlite3/execute_2.py |
|
457 |
|
458 :meth:`execute` will only execute a single SQL statement. If you try to execute |
|
459 more than one statement with it, it will raise a Warning. Use |
|
460 :meth:`executescript` if you want to execute multiple SQL statements with one |
|
461 call. |
|
462 |
|
463 |
|
464 .. method:: Cursor.executemany(sql, seq_of_parameters) |
|
465 |
|
466 Executes an SQL command against all parameter sequences or mappings found in |
|
467 the sequence *sql*. The :mod:`sqlite3` module also allows using an |
|
468 :term:`iterator` yielding parameters instead of a sequence. |
|
469 |
|
470 .. literalinclude:: ../includes/sqlite3/executemany_1.py |
|
471 |
|
472 Here's a shorter example using a :term:`generator`: |
|
473 |
|
474 .. literalinclude:: ../includes/sqlite3/executemany_2.py |
|
475 |
|
476 |
|
477 .. method:: Cursor.executescript(sql_script) |
|
478 |
|
479 This is a nonstandard convenience method for executing multiple SQL statements |
|
480 at once. It issues a ``COMMIT`` statement first, then executes the SQL script it |
|
481 gets as a parameter. |
|
482 |
|
483 *sql_script* can be a bytestring or a Unicode string. |
|
484 |
|
485 Example: |
|
486 |
|
487 .. literalinclude:: ../includes/sqlite3/executescript.py |
|
488 |
|
489 |
|
490 .. method:: Cursor.fetchone() |
|
491 |
|
492 Fetches the next row of a query result set, returning a single sequence, |
|
493 or :const:`None` when no more data is available. |
|
494 |
|
495 |
|
496 .. method:: Cursor.fetchmany([size=cursor.arraysize]) |
|
497 |
|
498 Fetches the next set of rows of a query result, returning a list. An empty |
|
499 list is returned when no more rows are available. |
|
500 |
|
501 The number of rows to fetch per call is specified by the *size* parameter. |
|
502 If it is not given, the cursor's arraysize determines the number of rows |
|
503 to be fetched. The method should try to fetch as many rows as indicated by |
|
504 the size parameter. If this is not possible due to the specified number of |
|
505 rows not being available, fewer rows may be returned. |
|
506 |
|
507 Note there are performance considerations involved with the *size* parameter. |
|
508 For optimal performance, it is usually best to use the arraysize attribute. |
|
509 If the *size* parameter is used, then it is best for it to retain the same |
|
510 value from one :meth:`fetchmany` call to the next. |
|
511 |
|
512 .. method:: Cursor.fetchall() |
|
513 |
|
514 Fetches all (remaining) rows of a query result, returning a list. Note that |
|
515 the cursor's arraysize attribute can affect the performance of this operation. |
|
516 An empty list is returned when no rows are available. |
|
517 |
|
518 |
|
519 .. attribute:: Cursor.rowcount |
|
520 |
|
521 Although the :class:`Cursor` class of the :mod:`sqlite3` module implements this |
|
522 attribute, the database engine's own support for the determination of "rows |
|
523 affected"/"rows selected" is quirky. |
|
524 |
|
525 For ``DELETE`` statements, SQLite reports :attr:`rowcount` as 0 if you make a |
|
526 ``DELETE FROM table`` without any condition. |
|
527 |
|
528 For :meth:`executemany` statements, the number of modifications are summed up |
|
529 into :attr:`rowcount`. |
|
530 |
|
531 As required by the Python DB API Spec, the :attr:`rowcount` attribute "is -1 in |
|
532 case no ``executeXX()`` has been performed on the cursor or the rowcount of the |
|
533 last operation is not determinable by the interface". |
|
534 |
|
535 This includes ``SELECT`` statements because we cannot determine the number of |
|
536 rows a query produced until all rows were fetched. |
|
537 |
|
538 .. attribute:: Cursor.lastrowid |
|
539 |
|
540 This read-only attribute provides the rowid of the last modified row. It is |
|
541 only set if you issued a ``INSERT`` statement using the :meth:`execute` |
|
542 method. For operations other than ``INSERT`` or when :meth:`executemany` is |
|
543 called, :attr:`lastrowid` is set to :const:`None`. |
|
544 |
|
545 .. attribute:: Cursor.description |
|
546 |
|
547 This read-only attribute provides the column names of the last query. To |
|
548 remain compatible with the Python DB API, it returns a 7-tuple for each |
|
549 column where the last six items of each tuple are :const:`None`. |
|
550 |
|
551 It is set for ``SELECT`` statements without any matching rows as well. |
|
552 |
|
553 .. _sqlite3-row-objects: |
|
554 |
|
555 Row Objects |
|
556 ----------- |
|
557 |
|
558 .. class:: Row |
|
559 |
|
560 A :class:`Row` instance serves as a highly optimized |
|
561 :attr:`~Connection.row_factory` for :class:`Connection` objects. |
|
562 It tries to mimic a tuple in most of its features. |
|
563 |
|
564 It supports mapping access by column name and index, iteration, |
|
565 representation, equality testing and :func:`len`. |
|
566 |
|
567 If two :class:`Row` objects have exactly the same columns and their |
|
568 members are equal, they compare equal. |
|
569 |
|
570 .. versionchanged:: 2.6 |
|
571 Added iteration and equality (hashability). |
|
572 |
|
573 .. method:: keys |
|
574 |
|
575 This method returns a tuple of column names. Immediately after a query, |
|
576 it is the first member of each tuple in :attr:`Cursor.description`. |
|
577 |
|
578 .. versionadded:: 2.6 |
|
579 |
|
580 Let's assume we initialize a table as in the example given above:: |
|
581 |
|
582 conn = sqlite3.connect(":memory:") |
|
583 c = conn.cursor() |
|
584 c.execute('''create table stocks |
|
585 (date text, trans text, symbol text, |
|
586 qty real, price real)''') |
|
587 c.execute("""insert into stocks |
|
588 values ('2006-01-05','BUY','RHAT',100,35.14)""") |
|
589 conn.commit() |
|
590 c.close() |
|
591 |
|
592 Now we plug :class:`Row` in:: |
|
593 |
|
594 >>> conn.row_factory = sqlite3.Row |
|
595 >>> c = conn.cursor() |
|
596 >>> c.execute('select * from stocks') |
|
597 <sqlite3.Cursor object at 0x7f4e7dd8fa80> |
|
598 >>> r = c.fetchone() |
|
599 >>> type(r) |
|
600 <type 'sqlite3.Row'> |
|
601 >>> r |
|
602 (u'2006-01-05', u'BUY', u'RHAT', 100.0, 35.140000000000001) |
|
603 >>> len(r) |
|
604 5 |
|
605 >>> r[2] |
|
606 u'RHAT' |
|
607 >>> r.keys() |
|
608 ['date', 'trans', 'symbol', 'qty', 'price'] |
|
609 >>> r['qty'] |
|
610 100.0 |
|
611 >>> for member in r: print member |
|
612 ... |
|
613 2006-01-05 |
|
614 BUY |
|
615 RHAT |
|
616 100.0 |
|
617 35.14 |
|
618 |
|
619 |
|
620 .. _sqlite3-types: |
|
621 |
|
622 SQLite and Python types |
|
623 ----------------------- |
|
624 |
|
625 |
|
626 Introduction |
|
627 ^^^^^^^^^^^^ |
|
628 |
|
629 SQLite natively supports the following types: ``NULL``, ``INTEGER``, |
|
630 ``REAL``, ``TEXT``, ``BLOB``. |
|
631 |
|
632 The following Python types can thus be sent to SQLite without any problem: |
|
633 |
|
634 +-----------------------------+-------------+ |
|
635 | Python type | SQLite type | |
|
636 +=============================+=============+ |
|
637 | :const:`None` | ``NULL`` | |
|
638 +-----------------------------+-------------+ |
|
639 | :class:`int` | ``INTEGER`` | |
|
640 +-----------------------------+-------------+ |
|
641 | :class:`long` | ``INTEGER`` | |
|
642 +-----------------------------+-------------+ |
|
643 | :class:`float` | ``REAL`` | |
|
644 +-----------------------------+-------------+ |
|
645 | :class:`str` (UTF8-encoded) | ``TEXT`` | |
|
646 +-----------------------------+-------------+ |
|
647 | :class:`unicode` | ``TEXT`` | |
|
648 +-----------------------------+-------------+ |
|
649 | :class:`buffer` | ``BLOB`` | |
|
650 +-----------------------------+-------------+ |
|
651 |
|
652 This is how SQLite types are converted to Python types by default: |
|
653 |
|
654 +-------------+----------------------------------------------+ |
|
655 | SQLite type | Python type | |
|
656 +=============+==============================================+ |
|
657 | ``NULL`` | :const:`None` | |
|
658 +-------------+----------------------------------------------+ |
|
659 | ``INTEGER`` | :class:`int` or :class:`long`, | |
|
660 | | depending on size | |
|
661 +-------------+----------------------------------------------+ |
|
662 | ``REAL`` | :class:`float` | |
|
663 +-------------+----------------------------------------------+ |
|
664 | ``TEXT`` | depends on :attr:`~Connection.text_factory`, | |
|
665 | | :class:`unicode` by default | |
|
666 +-------------+----------------------------------------------+ |
|
667 | ``BLOB`` | :class:`buffer` | |
|
668 +-------------+----------------------------------------------+ |
|
669 |
|
670 The type system of the :mod:`sqlite3` module is extensible in two ways: you can |
|
671 store additional Python types in a SQLite database via object adaptation, and |
|
672 you can let the :mod:`sqlite3` module convert SQLite types to different Python |
|
673 types via converters. |
|
674 |
|
675 |
|
676 Using adapters to store additional Python types in SQLite databases |
|
677 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
678 |
|
679 As described before, SQLite supports only a limited set of types natively. To |
|
680 use other Python types with SQLite, you must **adapt** them to one of the |
|
681 sqlite3 module's supported types for SQLite: one of NoneType, int, long, float, |
|
682 str, unicode, buffer. |
|
683 |
|
684 The :mod:`sqlite3` module uses Python object adaptation, as described in |
|
685 :pep:`246` for this. The protocol to use is :class:`PrepareProtocol`. |
|
686 |
|
687 There are two ways to enable the :mod:`sqlite3` module to adapt a custom Python |
|
688 type to one of the supported ones. |
|
689 |
|
690 |
|
691 Letting your object adapt itself |
|
692 """""""""""""""""""""""""""""""" |
|
693 |
|
694 This is a good approach if you write the class yourself. Let's suppose you have |
|
695 a class like this:: |
|
696 |
|
697 class Point(object): |
|
698 def __init__(self, x, y): |
|
699 self.x, self.y = x, y |
|
700 |
|
701 Now you want to store the point in a single SQLite column. First you'll have to |
|
702 choose one of the supported types first to be used for representing the point. |
|
703 Let's just use str and separate the coordinates using a semicolon. Then you need |
|
704 to give your class a method ``__conform__(self, protocol)`` which must return |
|
705 the converted value. The parameter *protocol* will be :class:`PrepareProtocol`. |
|
706 |
|
707 .. literalinclude:: ../includes/sqlite3/adapter_point_1.py |
|
708 |
|
709 |
|
710 Registering an adapter callable |
|
711 """"""""""""""""""""""""""""""" |
|
712 |
|
713 The other possibility is to create a function that converts the type to the |
|
714 string representation and register the function with :meth:`register_adapter`. |
|
715 |
|
716 .. note:: |
|
717 |
|
718 The type/class to adapt must be a :term:`new-style class`, i. e. it must have |
|
719 :class:`object` as one of its bases. |
|
720 |
|
721 .. literalinclude:: ../includes/sqlite3/adapter_point_2.py |
|
722 |
|
723 The :mod:`sqlite3` module has two default adapters for Python's built-in |
|
724 :class:`datetime.date` and :class:`datetime.datetime` types. Now let's suppose |
|
725 we want to store :class:`datetime.datetime` objects not in ISO representation, |
|
726 but as a Unix timestamp. |
|
727 |
|
728 .. literalinclude:: ../includes/sqlite3/adapter_datetime.py |
|
729 |
|
730 |
|
731 Converting SQLite values to custom Python types |
|
732 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
733 |
|
734 Writing an adapter lets you send custom Python types to SQLite. But to make it |
|
735 really useful we need to make the Python to SQLite to Python roundtrip work. |
|
736 |
|
737 Enter converters. |
|
738 |
|
739 Let's go back to the :class:`Point` class. We stored the x and y coordinates |
|
740 separated via semicolons as strings in SQLite. |
|
741 |
|
742 First, we'll define a converter function that accepts the string as a parameter |
|
743 and constructs a :class:`Point` object from it. |
|
744 |
|
745 .. note:: |
|
746 |
|
747 Converter functions **always** get called with a string, no matter under which |
|
748 data type you sent the value to SQLite. |
|
749 |
|
750 :: |
|
751 |
|
752 def convert_point(s): |
|
753 x, y = map(float, s.split(";")) |
|
754 return Point(x, y) |
|
755 |
|
756 Now you need to make the :mod:`sqlite3` module know that what you select from |
|
757 the database is actually a point. There are two ways of doing this: |
|
758 |
|
759 * Implicitly via the declared type |
|
760 |
|
761 * Explicitly via the column name |
|
762 |
|
763 Both ways are described in section :ref:`sqlite3-module-contents`, in the entries |
|
764 for the constants :const:`PARSE_DECLTYPES` and :const:`PARSE_COLNAMES`. |
|
765 |
|
766 The following example illustrates both approaches. |
|
767 |
|
768 .. literalinclude:: ../includes/sqlite3/converter_point.py |
|
769 |
|
770 |
|
771 Default adapters and converters |
|
772 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
773 |
|
774 There are default adapters for the date and datetime types in the datetime |
|
775 module. They will be sent as ISO dates/ISO timestamps to SQLite. |
|
776 |
|
777 The default converters are registered under the name "date" for |
|
778 :class:`datetime.date` and under the name "timestamp" for |
|
779 :class:`datetime.datetime`. |
|
780 |
|
781 This way, you can use date/timestamps from Python without any additional |
|
782 fiddling in most cases. The format of the adapters is also compatible with the |
|
783 experimental SQLite date/time functions. |
|
784 |
|
785 The following example demonstrates this. |
|
786 |
|
787 .. literalinclude:: ../includes/sqlite3/pysqlite_datetime.py |
|
788 |
|
789 |
|
790 .. _sqlite3-controlling-transactions: |
|
791 |
|
792 Controlling Transactions |
|
793 ------------------------ |
|
794 |
|
795 By default, the :mod:`sqlite3` module opens transactions implicitly before a |
|
796 Data Modification Language (DML) statement (i.e. |
|
797 ``INSERT``/``UPDATE``/``DELETE``/``REPLACE``), and commits transactions |
|
798 implicitly before a non-DML, non-query statement (i. e. |
|
799 anything other than ``SELECT`` or the aforementioned). |
|
800 |
|
801 So if you are within a transaction and issue a command like ``CREATE TABLE |
|
802 ...``, ``VACUUM``, ``PRAGMA``, the :mod:`sqlite3` module will commit implicitly |
|
803 before executing that command. There are two reasons for doing that. The first |
|
804 is that some of these commands don't work within transactions. The other reason |
|
805 is that pysqlite needs to keep track of the transaction state (if a transaction |
|
806 is active or not). |
|
807 |
|
808 You can control which kind of ``BEGIN`` statements pysqlite implicitly executes |
|
809 (or none at all) via the *isolation_level* parameter to the :func:`connect` |
|
810 call, or via the :attr:`isolation_level` property of connections. |
|
811 |
|
812 If you want **autocommit mode**, then set :attr:`isolation_level` to None. |
|
813 |
|
814 Otherwise leave it at its default, which will result in a plain "BEGIN" |
|
815 statement, or set it to one of SQLite's supported isolation levels: "DEFERRED", |
|
816 "IMMEDIATE" or "EXCLUSIVE". |
|
817 |
|
818 |
|
819 |
|
820 Using pysqlite efficiently |
|
821 -------------------------- |
|
822 |
|
823 |
|
824 Using shortcut methods |
|
825 ^^^^^^^^^^^^^^^^^^^^^^ |
|
826 |
|
827 Using the nonstandard :meth:`execute`, :meth:`executemany` and |
|
828 :meth:`executescript` methods of the :class:`Connection` object, your code can |
|
829 be written more concisely because you don't have to create the (often |
|
830 superfluous) :class:`Cursor` objects explicitly. Instead, the :class:`Cursor` |
|
831 objects are created implicitly and these shortcut methods return the cursor |
|
832 objects. This way, you can execute a ``SELECT`` statement and iterate over it |
|
833 directly using only a single call on the :class:`Connection` object. |
|
834 |
|
835 .. literalinclude:: ../includes/sqlite3/shortcut_methods.py |
|
836 |
|
837 |
|
838 Accessing columns by name instead of by index |
|
839 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
840 |
|
841 One useful feature of the :mod:`sqlite3` module is the builtin |
|
842 :class:`sqlite3.Row` class designed to be used as a row factory. |
|
843 |
|
844 Rows wrapped with this class can be accessed both by index (like tuples) and |
|
845 case-insensitively by name: |
|
846 |
|
847 .. literalinclude:: ../includes/sqlite3/rowclass.py |
|
848 |
|
849 |
|
850 Using the connection as a context manager |
|
851 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
|
852 |
|
853 .. versionadded:: 2.6 |
|
854 |
|
855 Connection objects can be used as context managers |
|
856 that automatically commit or rollback transactions. In the event of an |
|
857 exception, the transaction is rolled back; otherwise, the transaction is |
|
858 committed: |
|
859 |
|
860 .. literalinclude:: ../includes/sqlite3/ctx_manager.py |