Definitely agree. Caught the missing nullhandler behavior when
logging is off too... though didn't make the connection that this was
likely intended to handle that case.
It might make more sense to put this logic in conf/__init__.py
following the calls to configure the logger. Though that doesn'
f handlers... ie:
logger = logging.getLogger('adsf')
if not logger.handlers:
dictConfig(settings.LOGGING)
I feel like that check is unnecessary anyhow... but I guess that's how
you'd do it if it is necessary.
-k
On Fri, Oct 1, 2010 at 8:54 AM, Vinay Sajip wrote:
> On Oct 1,
I feel like something like this would be better suited to be in an
external application... since it will fail without a cache-backend.
Also, the implementation will have to change as Russell is about to
commit a logging patch with ticket #12012.
This would be best suited though for a custom handl
re: verbose logging configuration.
This bothered me as well initially, though after starting to use
logging extensively I realized that there isn't really a more concise
way to provide all of the features that the logging config brings to
the table.
We can however, create a very concise default s
Lumberjack is basically a backport of what I'd like built-in logging
support to be. I also have it built-in to django on my experimental
branch on github...
To over-ride the default email behavior just turn on the 500handler
view in lumberjack. This is what I perceive as the best method of
catch
Could be good to include some text about using the python loggers on
that WSGI debug page, rather than relying on the apache logging
mechanisms.
In django land ... there's django-devserver, django-debugtoolbar, and
django-lumberjack.
All of them more or less share the same profilers and such. Th
> For a very high traffic project backed by 20+ DB servers
Slightly OT, but MySQL performance related...
If you are write heavy, there's another issue that I imagine would
bring significant gains on a MyISAM setup of that proportion... and
possibly other databases to a lesser degree (the locking m
"I agree, and while we're at it also change the settings.py template to
just point to urls instead of project_name.urls"
Indeed, always the first thing I change when I start a project...
Having the project_name there means you are including the directory
above your project in the python path in yo
This abstract base class likely is a bit less performant than having
in-db support for cascades in pgsql... though it should give you the
behavior you are seeking.
It should set to default, or null if allowed.
Enjoy.
-k
class ClearOnDelete(models.Model):
def delete(self):
related_obje
This was not a "hey you guys are lazy", actually came across it ...
after I had fixed the same issue.
I just posted a patch for you generated off trunk... and left a
hopefully somewhat entertaining explanation of the details surrounding
the issues.
-k
--
You received this message because you ar
http://code.djangoproject.com/ticket/10758
Can we fix this? It's a pretty easy fix.
thanks,
-k
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from
I added a AdminEmailHandler to my branch and pulled the upstream
changes.
http://github.com/kevin/django-experimental/
It now behaves very close to how django-trunk does on exception ... by
default there is a streamhandler pushing to stderr and the admin email
handler pushing emails to admins.
T
p in log/messages if that's what you assumed ...
it should be caught by the default apache loggers at minimum, or be
sent to your vhost log if you have logging setup per virtual host.
-k
On May 28, 8:30 pm, Vinay Sajip wrote:
> On May 28, 10:27 pm, Kevin howerton wrote:
>
> > Indeed,
"Yes, something like that is a fairly minimal configuration, but
generally I've found a file-based log to be pretty much part of every
site's requirement, for anything but the smallest (toy) site."
Indeed, though that config does exactly that with apache ... the
streamhandler by default spits ever
I see the utility of being able to have additional ways to setup the
logging, though as it is I think the biggest issue people have with
the logging stuff is that the dictconfig is already fairly
intimidating looking. If someone really wants to disable the default
setup of logging, it should be as
On Wed, May 5, 2010 at 3:48 PM, Jacob Kaplan-Moss wrote:
> On Wed, May 5, 2010 at 1:53 PM, Kevin Howerton
> wrote:
>> Where django pulls a 500 it should call these two lines, which will
>> dump the exception raised to stderr.
>>
>> type, value, traceback
in production.
-k
On Wed, May 5, 2010 at 1:51 PM, Karen Tracey wrote:
> On Wed, May 5, 2010 at 12:46 PM, Kevin Howerton
> wrote:
>>
>> What I was suggesting in my post though, was that we alter the default
>> CRITICAL error handling behavior ... as it stands (by default
I did.
On Wed, May 5, 2010 at 12:56 PM, Jacob Kaplan-Moss wrote:
> On Wed, May 5, 2010 at 11:48 AM, Kevin Howerton
> wrote:
>> ps. I don't want to get into a flamewar
>
> Then next time leave out the rambling, ad hominems, and sweeping
> generalizations. Focu
#x27;s very reductionist. Ignoring prior art just
because it was written in ruby, or targets rails, or runs on the JVM,
or uses CamelCase for function names is stupid.
On Wed, May 5, 2010 at 4:17 AM, Vinay Sajip wrote:
>
> On May 5, 4:47 am, Kevin Howerton wrote:
>
> I think the plan was t
#x27;s very reductionist. Ignoring prior art just
because it was written in ruby, or targets rails, or runs on the JVM,
or uses CamelCase for function names is stupid.
On Wed, May 5, 2010 at 4:17 AM, Vinay Sajip wrote:
>
> On May 5, 4:47 am, Kevin Howerton wrote:
>
> I think the plan was t
#x27;s very reductionist. Ignoring prior art just
because it was written in ruby, or targets rails, or runs on the JVM,
or uses CamelCase for function names is stupid.
On Wed, May 5, 2010 at 4:17 AM, Vinay Sajip wrote:
>
> On May 5, 4:47 am, Kevin Howerton wrote:
>
> I think the plan was t
Realized today that by default django more or less suppresses errors
sent to stderr when debug is off. Well I guess it uses email sent to
admins by default. Though, I distinctly remember stderr being sent
into my apache logs for some reason. Maybe this was when I was using
mod_python rather than
>Nothing I've seen so far solves, or even addresses the original need for
>_not_ sourcing the same script numerous times (thanks to widgets with
>their own media)
The widget and admin media system needs to be re-evaluated IMO
none of these solutions are going to address the flaws you are
refer
The django-compress looks a bit better as it has the option to do the
versioning (based on a file hash), compression, and concatenization
with a management command.
Django_compressor does this all on page load, which is not production
worthy IMO.
Generating an MD5 hash on page load is un-needed ov
>From the github:
"* Commits should be atomic: they should each encompass a single logical
change that works on its own. You can use "git rebase --interactive" to
collapse multiple commits into a single commit before pushing your code
up for contribution."
I think the idea is to basi
"I understand that Django has historically been
anti-javascript-framework-blessing, and I'm wondering if opening this
can of worms would mean having to incorporate some kind of a pluggable
backend system (for working with different frameworks, or multiple
frameworks at a time) - something I've brie
Thanks for the support Russ...
I think Cujo (the name at least) has been abandoned and I have joined my
efforts with some other developers also interested in contributing to an
experimental branch.
http://github.com/tomxtobin/django-experimental
http://groups.google.com/group/django-experimental?
Cujo... for starters it's Amon Tobin's first moniker (he remixes jazz
into some delightful tunes, if you don't know of him I strongly
recommend you go to your local record store and pick up a copy of
"Adventures in Foam").
Also, I felt it was somewhat apt due to the rabid nature of the
discussions
"That is, in fact, our policy. 1.1 is compatible with 1.0; 1.2 with 1.1; etc."
1.1 and 1.2 are by definition not point releases. Point releases
don't introduce new features.
On Thu, Apr 15, 2010 at 3:32 PM, Jacob Kaplan-Moss wrote:
> On Thu, Apr 15, 2010 at 1:57 PM, Kevin
Why not just use the backend feature that already exists?
I have an S3 backend that does this...
It checks if it's on S3, if not it serves it locally. If it's on S3
it throws the url into memcache, and bob is your uncle.
On Wed, Apr 14, 2010 at 9:27 AM, Russell Keith-Magee
wrote:
> On Wed, Apr
"You seem to be suggesting that a fork will somehow magically fix the
speed of Django development. I ask you: who is going to work on this
fork?"
I think a hostile fork is almost a certain outcome if development
continues as it has. Not only is the resistance to make backwards
incompatible change
c wit henceforth, as it clearly doesn't translate
well on the internet.
sorry again.
-k
On Tue, Apr 6, 2010 at 12:14 AM, Jacob Kaplan-Moss wrote:
> On Mon, Apr 5, 2010 at 1:06 PM, Kevin howerton
> wrote:
>> ps. I didn't really murder a hooker in vegas
>
> This s
cket/7539
>
> But I like your imagination, or is there more truth behind your story
> than you'd admit?
>
> Cheers,
> Florian Apolloner
>
> On Apr 5, 8:06 pm, Kevin howerton wrote:
>> Hi.
>>
>> So I came across a use-case for wanting to delete conte
Hi.
So I came across a use-case for wanting to delete content (which
django doesn't really handle exactly to my liking). I just got back
from a vacation in vegas and noticed in a drunken stupor I had posted
some pictures on my blog that should I really shouldn't have (
http://i.imgur.com/5oj15.jp
34 matches
Mail list logo