On Thu, Mar 27, 2008 at 9:30 AM, Michael Radziej <[EMAIL PROTECTED]> wrote:
> I see one possible problem: I observe that mysql always slurps in the
> whole result set from the database when you only issue a select
> (cursor.query(...))
*Sigh*.
> Theoretically, it's probably possible to work around this, since the C API
> has a function to free the result set.
Meh, that sounds like a huge headache waiting to happen.
> Another solution could be to let the
> database backend decide whether it's better to use count() instead.
This could work: MySQL cheats and makes COUNT(*) pretty fast, so it's
probably not a bad idea to use it if available. It won't fill the
result cache which means the typical::
if qs:
for x in qs:
...
(which is what's being optomized for here) won't be as fast as it should be.
I actually think this is pretty easy now -- check out how the Oracle
backend provides a custom QuerySet subclass; the MySQL backend could
redefine __nonzero__.
Jacob
[Of course, what I'd *really* like to do is just leave it slow. When
folks complain, we can just tell them to use PostgreSQL :).
</tech-bigot>.]
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
