There are still a couple of enhancements to do, but I've decided they're
not worth holding up the entire branch for. I can just as easily do them
Thanks to everybody who reported bugs and tested things. Thanks
especially to Justin Bronn and Ian Kelly for lots of patches and testing
to get the Oracle backend up to scratch on the branch.
Detailed list of changes is in the branch's wiki page () and if
you're interested in seeing the documentation additions and changes, you
can view .
No more bugs should now be reported against the queryset-refactor
version. The branch is closed.
On the other hand, you have different fingers.
w00t! Great work Malcolm. This is a big change, a long time coming,
but well worth the wait. Thanks for all the effort you have put into
getting this done.
I doubt that they're likely to change. as_sql() is basically the
"public" (in the sense that Query isn't public API, but it's
developer-exposed API) way to get the SQL -- particularly needed for
writing subqueries and the like.
At some point we need to update the FAQ question, since as_sql() is
equivalent to, but easier than, db.connection.queries[-1]['sql'] (and
happens before the event).
Note, however, that as_sql() doesn't always return something. There is a
shortcut built in when we know nothing can match (the
MyModel.objects.filter(pk__in=) situation) and in that case as_sql()
will raise an exception which is caught in the database execution code;
i.e. it's a feature, not a bug. That's rare enough not to be a real
problem, though, and if MySQL didn't misimplement "pk is NULL" by
overloading its behaviour we wouldn't even need that (although the
shortcut is faster).
> Also, how hard would it be to get the __str__() representation of a
> Query to be escaped using the current database's escaping syntax? It
> seems like it could be a bit of a fiddle as Python's DB-API doesn't
> require database engines to expose that ability,
Well, that's really the problem: it's not exposed at all, so would
require extra code for every single backend, since it requires diving
into undocumented interfaces in some cases. For this reason, I've
personally gotten into the habit of only using as_sql(), so that it's
clear where the parameters will be substituted and what the parameters
are. I find the __str__() output a little harder to parse.
> but it would be
> extremely useful for testing - it would mean you could copy and paste
> SQL directly from Python's interactive prompt (or from the Django SQL
> query log) and paste it in to a mysql interactive shell, which would
> help with debugging tricky SQL.
Agreed, in theory. We take patches. :-)
I seem to remember I've fallen into the trap of implementing some of
your personal "wouldn't it be nice if..." features before. I'm wiser
Everything is _not_ based on faith... take my word for it.
I merged queryset-refactor into trunk just now. This was changeset r7477.