Hi Russell, On Mon, Aug 3, 2009 at 9:02 PM, Russell Keith-Magee<[email protected]> wrote: > > On Mon, Aug 3, 2009 at 7:48 PM, Ivan Sagalaev<[email protected]> > wrote: >> In this vein I propose to teach CursorDebugWrapper to log SQL queries >> into a named logger instead of storing them into connection.queries. >> Before writing a patch I want to discuss it. >> For backward compatibility there may be a custom logging handler that >> would maintain connection.queries as is. But the user will have to >> explicitly switch it on. > > For the record, there is one notable use for the legacy behavior - > debugging at the console. i.e., issue a query at the Python prompt, > then print connection.queries[-1] to see what was executed. This is a > small thing, but it is a feature that I have used myself on more than > one occasion. If we're going to abandon or deprecate > connection.queries, we need to have a substitute for this use case. Actually, for me, connection.queries caused more harm than good.
Django is lacking simple logger and logging client, that's why developers are using connection.queries now as a replacement, not vice versa as you're talking. 95% of cases, all I need is just to be able to see few last queries from the dev server in console, in the same way as I see server requests. I also want to be able to set up some builtin smtp server for the same reason if i have no real server on my dev box. And I believe these should be builtin features, since nearly all users will use them. tail -f queries.log would be ok, if someone logged it down for me already. And filling all PC memory with connection.queries and crashing/swapping when you do mass insert of few million records from django shell into database is awful thing that needs to be dealt with somehow! > However, more broadly, my concern with this proposal is the extent to > which it overlaps with logs already provided by the actual database. > Most databases have extremely configurable logging and analysis tools > - if Django started moving into this territory for logging queries, we > would be duplicating functionality pretty much from day 1. To pick > just one example: slow query analysers are a feature offered by most > serious databases, and provide much more detail than a single line in > a log file. 1) On shared hosting, you are not able to alter database configuration, that means, this option is not even possible. 2) On real world projects, you want different projects to use different database logging levels, while having single database. What I'm saying, is that despite the fact you are able to set up logging on the database level, this is very rarely used, since not always can be used, hard in customization and not always can be customized to the level you need. > I'm not saying that what you are proposing this isn't worth doing - > just that we need to be careful that we're not duplicating effort on > tools that are already available (and better) elsewhere. The "memory > leak" issue, for example, is definitely something that we should > address. Ensuring that django-debug-toolbar (and others) have access > to adequate internal data is another admirable goal. Is logging the > way to fix these problems? I'm not necessarily convinced. I suspect > more discussion is required. I see it in the way that django-debug-toolbar should set up a hook if it needs some queries data. connection.queries looks like a hack and can be easily eliminated and substituted without losing any features. It's reliance on settings.DEBUG option is also a bit weird. There's no option QUERY_DEBUG, it's being set up in static way, and what we are supposed to do with this option after django multidb integration? -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: [email protected] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
