Opened 17 years ago
Closed 15 years ago
#6047 closed (fixed)
db-api docs: invalid REGEX SQL equiv for SQLite
Reported by: | Owned by: | holdenweb | |
---|---|---|---|
Component: | Documentation | Version: | dev |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
On the documentation/db-api/ page, under REGEX, the following
"In the case of SQLite, which doesn’t natively support regular-expression lookups, the syntax is that of Python’s re module."
doesn't match this line
SQL equivalents:
SELECT ... WHERE title REGEXP '^(An?|The) +'; -- SQLite
This should be removed, or a SQL + pythen re equiv should be put in its place.
Attachments (2)
Change History (10)
comment:1 by , 17 years ago
Needs documentation: | set |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 17 years ago
Description: | modified (diff) |
---|
comment:3 by , 17 years ago
comment:4 by , 17 years ago
It doesn't seem to me correct or useful to list a SQLite SQL equivalent if there isn't one.
If you're going to leave it, my suggestion would be to move the line
"In the case of SQLite, which doesn’t natively support regular-expression lookups, the syntax is that of Python’s re module."
to directly below the code block of SQL equivs. This would put the two lines closer together, reducing the chance that someone would see the SQLite example without the accompanying/qualifying note (especially as a similar equiv appears in IREGEX, relying on this note for clarification)
Perhaps format it as a note? Add an asterisk after the -- SQLite?
comment:5 by , 17 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:6 by , 17 years ago
Has patch: | set |
---|
I would suggest that the structure of the documentation be left as it is, and the offending sentence be changed. I have attached a patch for db-api.txt (see 6047.diff).
Hopefully this will explain why the SQL looks like it does (since it is indeed the SQL that is sent to the SQLite engine in the case given).
Those seeking light relief may wish to consult http://holdenweb.blogspot.com/2008/04/for-want-of-nail.html concerning the history of the associated patch.
comment:7 by , 15 years ago
Needs documentation: | unset |
---|---|
Triage Stage: | Accepted → Ready for checkin |
comment:8 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
It's not entirely clear to me what the problem is you're pointing out here. Given that we don't want to remove the line, could you suggest an alternative formulation (it's a balance between acknowledging that SQLite actually uses Python to do some of the heavy lifting here, without bogging the documentation down in relatively minor details at this point). Any suggestions on what we could do to make it clearer?