On Sat, Mar 12, 2011 at 12:20 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > Hi Christophe -- > > Interesting; I didn't know about these constructs. > > I'm not opposed to this change, but I am a bit concerned about opening > up the ability to use raw() for stuff like UPDATE/DELETE where it'd be > a nasty code smell. I'd be interested in your thoughts on that: is > there a way we can prevent folks from shooting themselves in the foot > this way, or do you think trying itself is futile?
The more I look at this, the more I think any protection is going to be pretty much futile. We could spend a whole lot of time trying to validate all the possible combinations and permutations, and still end up missing viable options on certain databases, or miscategorizing valid calls because of some edge case of parsing (oh - you have a space *before* the third brace...better open a ticket). I think we'd be much better served to document the fact that raw() expects a row of results to be returned from the SQL it is provided, and leave the rest up to consenting adults. We might be able to clean up the UX a bit with error messages that draw attention to the known limitations, but honestly, I don't have any particular problem with an API called "raw" requiring the user to be awake and alert when using it. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
