#6429 closed defect (worksforme)
sqlite backend should accept valid sqlite strings
Reported by: | Owned by: | Jonas Borgström | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | general | Version: | |
Severity: | minor | Keywords: | sqlite |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
I'm maintainer of AuthOpenIdPluging for Trac (http://trac-hacks.org/wiki/AuthOpenIdPlugin).
Recently one user of my plugin found problem (http://trac-hacks.org/ticket/2242) that must be fixed in trac side in my opinion.
If we supply following SQL string:
'SELECT handle, secret, issued, lifetime, assoc_type FROM oid_associations WHERE server_url = ?;'
to sqlite backend it fails at line:
sql = sql % (('?',) * len(args)) File "/home/user/server/lib/python2.5/Trac-0.11dev_r6254-py2.5.egg/trac/db/sqlite_backend.py", line 56, in execute
with exception:
TypeError: not all arguments converted during string formatting
SQL string is completely valid sqlite string. I'm not sure yet how fix should look like however.
Attachments (0)
Change History (3)
comment:1 by , 17 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:2 by , 17 years ago
Yes, I understand that but that makes new problem. Python OpenId library has different backends based on database type (instead of trying to be univeral like trac it is specific for each database type). As result it already has correct sqlite SQL strings. Because trac tries to be universal (multi-DB) it is not possible to skip that params enforcement and use python openid library directly. I'm pretty sure that if there are more database type oriented libraries (at least for sqlite) they are almost impossible to use with trac.
comment:3 by , 17 years ago
Sure, just pass it the underlying DB connection object, not the Trac one, self.env.get_db_cnx().cnx
.
Trac's database layer enforces the
%s
paramstyle in all backends to allow for mutli-DB support. Just look at any use cursors in the Trac codebase itself.