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
= 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 <vinay_sa...@yahoo.co.uk> wrote:
> On Oct 1, 3:45 am, Kevin
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
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
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
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.
> 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
"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
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):
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
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.
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 <vinay_sa...@yahoo.co.uk> wrote:
> On May 28, 10:27 pm, Kevin howerton <kevin.hower...@gmai
"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
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
M, Karen Tracey <kmtra...@gmail.com> wrote:
> On Wed, May 5, 2010 at 12:46 PM, Kevin Howerton <kevin.hower...@gmail.com>
> wrote:
>>
>> What I was suggesting in my post though, was that we alter the default
>> CRITICAL error handling behavior ... as it sta
I did.
On Wed, May 5, 2010 at 12:56 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Wed, May 5, 2010 at 11:48 AM, Kevin Howerton
> <kevin.hower...@gmail.com> wrote:
>> ps. I don't want to get into a flamewar
>
> Then next time leave out the rambl
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 <vinay_sa...@yahoo.co.uk> wrote:
>
> On May 5, 4:47 am, Kevin Howerton <kevin.hower...@gmail.com> wrote:
>
> I th
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 <vinay_sa...@yahoo.co.uk> wrote:
>
> On May 5, 4:47 am, Kevin Howerton <kevin.hower...@gmail.com> wrote:
>
> I th
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 <vinay_sa...@yahoo.co.uk> wrote:
>
> On May 5, 4:47 am, Kevin Howerton <kevin.hower...@gmail.com> wrote:
>
> I th
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
>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
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
>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
"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
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
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
"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 <ja...@jacobian.org> wrote:
> On Thu, Apr 15, 201
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
"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
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 <ja...@jacobian.org> wrote:
> On Mon, Apr 5, 2010 at 1:06 PM, Kevin howerton <kevin.hower...@gmail.com>
> wrote:
>> ps. I didn't really
ject.com/ticket/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 <kevin.hower...@gmail.com> wrote:
>> Hi.
>>
>> So I came across a
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 (
33 matches
Mail list logo
