#6396 closed defect (fixed)
Database parameter must be string
| Reported by: | Owned by: | Christian Boos | |
|---|---|---|---|
| Priority: | normal | Milestone: | 0.11 |
| Component: | general | Version: | devel |
| Severity: | normal | Keywords: | |
| Cc: | Branch: | ||
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
When I try run trac 0.11Dev_r6202 on pysqlite: 2.4.0 compiled with SQLite: 3.3.12 the trac/db/sqlite_backend.py throw pysqlite Exception
database parameter must be string
in line 172
Problematic us variable path, with value db/trac.db
Simple conversion
path - str( path )
correct this problem.
Attachments (0)
Change History (10)
comment:1 by , 18 years ago
comment:2 by , 18 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
th'x
Adding Trac 0.11dev-r6223
Trac work correct.
I like It - the most fastest bug fixing on the word :)
comment:3 by , 18 years ago
I'd consider this a bug of PySQLite.
What if I am a Japanese user that wants to use either hiragana/kanji for my path and database parts of the connection string?
comment:4 by , 18 years ago
Well, the unicode string is converted to utf-8, so SQLite should still be able to handle it (see http://www.sqlite.org/capi3ref.html#sqlite3_open).
It's maybe even working better now than before for that use case ;-)
comment:5 by , 18 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Gerhard will fix this in 2.4.1 so that unicode strings can be used again. Do we need to reopen the ticket as a reminder?
comment:6 by , 18 years ago
| Owner: | changed from to |
|---|---|
| Status: | reopened → new |
Let me sum up the status:
- Pysqlite < 2.4.0:
char* database; ... PyArg_ParseTupleAndKeywords(args, kwargs, "s|diOiOi", kwlist, &database ...
- Pysqlite 2.4.0:
PyObject* database; ... PyArg_ParseTupleAndKeywords(args, kwargs, "O|diOiOi", kwlist, &database, ... if (PyString_Check(database)) { ... sqlite3_open(PyString_AsString(database), ... - Pysqlite > 2.4.0: same as 2., only the test is now
if (PyString_Check(database) || PyUnicode_Check(database))
In 1. and 3., the unicode to str conversion that eventually takes place will use the sys.getdefaultencoding(), i.e. ascii most of the time.
So r6223 not only has the benefit of adding compatibility with 2., it also introduces support for non-ascii characters in the path for all the other versions, and as such, I think there's no need to rework that change.
References:
- [pysqlite 441/pysqlite/trunk/src/connection.c] for 1. and 2.
- [pysqlite 448/pysqlite/trunk/src/connection.c] for 3.
- http://www.python.org/doc/2.5/api/arg-parsing.html for the "s" specifier in
Py_ParseTuple
comment:7 by , 18 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Maybe in future versions, pysqlite could take care of doing an explicit utf-8 encoding of an input unicode string, as that's what SQLite expects, but this is not concerning Trac.



[6223:6224] made some corrections regarding pysqlite 2.4.0.
Could you update your Trac to current HEAD, and try again? Report back please.