On 4/20/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 4/20/06, Beegee <[EMAIL PROTECTED]> wrote:
> > No, then it also doesn't work. When I repeat the following query:
> >
> > cursor.execute('select * from wifidog_businesses limit 10')
> >
> > using MySQLdb the number of Cache hits do not increase. However, the
> > number of Qcache_queries_in_cache also do not increase. Strange.
> >
> > I did find an issue on the MySQL for Python Sourceforge website that
> > seems to be describing the exact same issue:
>
> Ah, so it's a MySQLdb issue -- good to know. Andy Dustman, who's
> involved in maintaining MySQLdb, hangs out on the Django mailing list,
> so he might be able to shed more light on the issue.I've reopened that bug, but I am very skeptical that anything in MySQLdb can be causing it. All the caching logic happens on the server side, and the only thing the client is required to do is to send the exact (byte-for-byte) same query, and have query_cache_type (either for SESSION or GLOBAL) set to 1, or else set query_cache_type to 2 and use SELECT SQL_CACHE. For Django you'd want the former. Plus, updating the tables used by the query invalidates the cache, but it doesn't sound like you're doing that, or at least not in your example. Do statements generated by Django have columns in a deterministic order? -- The Pythonic Principle: Python works the way it does because if it didn't, it wouldn't be Python. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~----------~----~----~----~------~----~------~--~---
