Opened 14 years ago
Closed 14 years ago
#14733 closed (fixed)
Allow Manager.raw() execute not only "Pure selects"
Reported by: | dzentoo | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | yes | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
Since the raw query validation only matches if the request startswith("select") I would like to execute queries like "(SELECT) UNION (SELECT)".
Attachments (2)
Change History (15)
by , 14 years ago
Attachment: | force_select_raw_queries.patch added |
---|
comment:1 by , 14 years ago
Needs tests: | set |
---|---|
Patch needs improvement: | set |
Triage Stage: | Unreviewed → Accepted |
Like I said in IRC - the use cases for raw() are fairly strictly limited to SELECT clauses; I'd rather see the validation logic improved to catch the edge cases, rather than just dropping validation.
comment:4 by , 14 years ago
Can raw() execute this kind of queries ?
http://www.davidcramer.net/code/django/6939/scaling-threaded-comments-on-django-at-disqus.html
comment:5 by , 14 years ago
Right now? No. Could it? Sure. You just need to make the validation sufficiently flexible.
comment:6 by , 14 years ago
Why are raw queries strictly limited to SELECT queries? Is this a security measure?
Seems like determining whether a query is a SELECT or not require a complex regex.
comment:7 by , 14 years ago
It's not a security measure -- it's a matter of basic functionality. The rest of the behavior of raw() deals with converting the returned results into Django objects. The query validation is purely about ensuring that the query will actually return results that can be converted into Django objects.
comment:8 by , 14 years ago
Well, I tried "sqlparse" without success ..
res = sqlparse.parse("(SELECT * FROM pouet LIMIT 5) UNION (SELECT * FROM repouet)") st = res[0] print st.get_type() 'UNKNOWN'
What If I match if the query does not contain UPDATE / INSERT / DELETE ?
what do you mean by 'flexible validation' ? Any idea on how you 'll proceed ?
comment:9 by , 14 years ago
Version: | 1.2 → SVN |
---|
http://thebuild.com/blog/2010/12/13/very-large-result-sets-in-django-using-postgresql/ also has a use case for wanting to use FETCH 1000 FROM gigantic_cursor
with raw()
.
Really, it feels like we're doing too much validation here - raw is supposed to be for the edge cases and we're artificially limiting how it can be used.
comment:10 by , 14 years ago
I think that the validation is trying too hard to make this foolproof. It's not practical to integrate into Django a validation across all possible backends to catch all and only set-returning statements that can be passed in. That's not even in a static set of operations (for example, right now, the DO statement in PostgreSQL can't return sets, but there are proposals to allow it to do so).
by , 14 years ago
Attachment: | 14733-xof.diff added |
---|
Per discussion on django-developers, a patch to remove the restrictions and update the documentation
attached patch