On 7/28/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Specifically, I could see (and I currently *have*) needs for the > following assertions: > > * Assert a given custom model method runs a certain, exact number of SQL > queries > > * Assert a given custom model method's SQL contains a certain string
Sounds like a reasonable request. > Maybe it's time to expose the underlying > queries in a more developer-friendly way. I can't say I have ever found myself unsatisfied with connection.queries, but I don't have any particular objections to replacing it. > django.db.connection.register_query_callback(lambda query: > sys.stderr.write(query)) A few elaboration questions: - What happens to connection.queries in this plan? Does it remain, but the callback to populate it only gets installed if DEBUG=True? Or are you suggesting that we don't provide query logging by default, but provide a utility callback that users can install on their own if they ever need query logging? - What happens to reset_queries? Does this listener still get installed on the request_started signal? If so, how does it integrate with the query callback? Russ %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
