On Tue, Apr 22, 2008 at 1:26 AM, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> Simon Willison wrote:
> > Of course, this behaviour is documented... but I think it's reasonable
> > to expect that many people will miss that part of the docs.
>
> Where? I didn't know about this and feel like I've
+1 because this is annoying behavior.
I ALWAYS run scripts with DEBUG on, that doesn't mean they're on a
production server, because these things are cronned. And I'm always
doing stuff that involves the shell, etc, (imports) where debug is on.
The first thing I've had to do in any shell session,
or more specifically:
http://www.djangoproject.com/documentation/faq/#why-is-django-leaking-memory
On Apr 21, 7:14 pm, "John-Scott Atlakson"
<[EMAIL PROTECTED]> wrote:
> On Mon, Apr 21, 2008 at 1:26 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> > Simon Willison wrote:
> > > Of course, this
On Mon, Apr 21, 2008 at 1:26 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> Simon Willison wrote:
> > Of course, this behaviour is documented... but I think it's reasonable
> > to expect that many people will miss that part of the docs.
>
> Where? I didn't know about this and feel like I've read
Simon Willison wrote:
> Of course, this behaviour is documented... but I think it's reasonable
> to expect that many people will miss that part of the docs.
Where? I didn't know about this and feel like I've read most of the
Django documentation and the Django book. I'm purposefully looking
On Mon, 2008-04-21 at 03:46 -0700, Simon Willison wrote:
> On Apr 20, 11:23 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> > -1 for the reasons that James Bennett stated above. That it crashes
> > and burns in production is actually a feature in this case.
>
> If we want to crash and
> If we want to crash and burn if you use DEBUG=True in
> production we should do that explicitly, not as a side effect
> of another feature. I think there is enough real-world
> evidence that people are being tripped up by this for
> legitimate reasons (running import scripts in development
>
On Apr 20, 11:23 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> -1 for the reasons that James Bennett stated above. That it crashes
> and burns in production is actually a feature in this case.
If we want to crash and burn if you use DEBUG=True in production we
should do that explicitly,
On Mon, 2008-04-21 at 01:50 -0700, ludvig.ericson wrote:
> On Apr 21, 12:40 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
> > -1 here too, for exactly the same reason. Add to that the inevitable
> > Murphyism that the one time you specify N=10 will be the time that the
> > 11th oldest
On Apr 21, 12:40 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> -1 here too, for exactly the same reason. Add to that the inevitable
> Murphyism that the one time you specify N=10 will be the time that the
> 11th oldest query will be the one causing the problem.
I agree, though my
Hello,
+1 from my side.
I agree with Simon's proposal and also the email above.
It is not really necessary to log *all* of queries also on development
servers. If there's something fishy going on nothing would stop me to enable
unlimited logging again.
Cheers,
Valts.
On Mon, Apr 21, 2008 at
Simon is right IMO, but not only for production server... what about
development and preproduction servers? Is usual in projects that you
deploy application in a server for customer or partners, and it's
better to set DEBUG mode for debugging purposes (of course),
tracebacks, URLs debugging, etc.
On Mon, Apr 21, 2008 at 6:23 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> -1 for the reasons that James Bennett stated above. That it crashes
> and burns in production is actually a feature in this case.
-1 here too, for exactly the same reason. Add to that the inevitable
Murphyism
-1 for the reasons that James Bennett stated above. That it crashes
and burns in production is actually a feature in this case.
- Eric Florenzano
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers"
I'm +1 on this.
Although, there was a mistake in one of the replies.
Simon's intended behaviour is:
DEBUG_SQL_LOG_LIMIT = 200 (logs last 200 queries)
DEBUG_SQL_LOG_LIMIT = None (logs all queries)
DEBUG_SQL_LOG_LIMIT = 0 (logs nothing)
Rob
On Apr 19, 8:37 am, Simon Willison <[EMAIL
+1 also, but I'll suggest keeping the ability to get aggregate
statistics, e.g.,
django.db.connection.total_queries
django.db.connection.total_query_time
(and maybe the whole queries list should be renamed as
django.db.connection.recent_queries, so as not to suggest that it's
actually all of
> What do people think of having the debug SQL log limited to only
> storing the last N queries, with N set to something sensible like 200
> by default? This behavior could be controlled by a setting so if
> people want to log everything they can:
>
> DEBUG_SQL_LOG_LIMIT = 200 # Set to 0 to
I'd second Simon's proposal. People often develop their projects on
production servers and need to have debug on. Having to manually flush
the query log disrupts their normal workflow. I'd suggest being kind
to the users and not work against their intuition by default. As Simon
proposed, whoever
On Sat, Apr 19, 2008 at 2:37 AM, Simon Willison <[EMAIL PROTECTED]> wrote:
> I've noticed that a LOT of people get bitten by the problem where
> every SQL statement is logged if DEBUG=True, resulting in huge memory
> consumption after a while. This problem seems particularly common for
>
I've noticed that a LOT of people get bitten by the problem where
every SQL statement is logged if DEBUG=True, resulting in huge memory
consumption after a while. This problem seems particularly common for
import scripts, which are often run in development (hence with DEBUG
on) and can involve
20 matches
Mail list logo
