Matt Schinckel wrote: > Are you sure it hits the db twice?
Of course not. But (modulo "Premature Optimization") I would be suspicious of any such statement, as I wrote it. I want to be able to answer your question, forever. Is there a way, from a developer test, to query "what SQL statement does this QuerySet generate"? A related question is "what are all the SQL statements that a given block of code create?" If I knew the answer to those questions, I could write an assertion that sends the output into EXPLAIN, and then detects atrocities, such as table reads. This would allow developer tests to fail as early as possible, without soak testing to detect the slow parts by brute force. And such an assertion would permit aggressive refactoring, without worrying that one refactor will silently slow everything down. Oh, also, a unified statement like "SELECT * WHERE id not in (SELECT id WHERE ...)" might just snocker the database worse than two SELECTs. You never know; that's why I'd like to see an EXPLAIN on it! -- Phlip http://c2.com/cgi/wiki?ZeekLand -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
