Escaping inputs for raw queries… and related problems

[KenWhitesell]

@typonaut

Arguing that this merely illustrates the abstraction of the Django code from the database (which I think is Ken’s point) is a fair defence to some extent (ie if you wanted to see the bones of the query before it was used), but I don’t really see it stands up very well, when, in this case the query has been executed and Django obviously knows the target database.

I agree that one might think that that’s how an ORM would work, but one would be wrong in thinking that Django’s ORM works that way.
It’s a bit opaque, I know, but when you’ve gotten a result set from a queryset, the queryset object itself is still a queryset. That you have passed it along to the database engine for execution / resolution does not change the nature of that queryset, and does not prevent you from subsequently executing that same queryset on a different database engine.
So no, the queryset does not “know” the target database. That information is not returned to the queryset.

I can understand the desire to get access to the actual SQL statement issued - See the thread at Database instrumentation at a higher layer for the solution I implemented for this.

@typonaut

The central problem being that I’m using data in in my tables that has come from other entities, there is lots of it, and that data is inherently messy – it’s more practical, for various reasons, to attempt to work around the mess, than to clean it up.

Yep, I deal with that type of situation a lot - and it’s one of Django’s limitations. Django does not fare well with databases that are not “classically normalized” - and there are many reasons why databases might be designed that way.