am, Jesse Young <[EMAIL PROTECTED]> wrote:
> Yeah, we found the ping() during performance profiling too. It's a
> significant performance hit -- it basically doubles the number of
> requests to the DB server. It seems that the reason is to support use
> cases where the DB c
Yeah, we found the ping() during performance profiling too. It's a
significant performance hit -- it basically doubles the number of
requests to the DB server. It seems that the reason is to support use
cases where the DB connection is long-lived, since sometimes DB
connections die if you leave th
> 3. Meta attribute formfield_kwargs for model forms
It seems like the arguments to form fields can already be customized
fairly easily using formfield_callback? In your example, I think you
could accomplish the same thing using formfield_callback like this:
formfield_callback = lambda f: f
PROTECTED]> wrote:
> On Oct 16, 8:29 pm, Jesse Young <[EMAIL PROTECTED]> wrote:
>
> > My idea (implemented in my local version of Django) was to
> > modify RegexURLResolver to return the urlpattern that was used, and
> > store that (as well as the kwargs) as a p
ere 1) compare the path or 2) manually specify the
active page name in a {% block %} tag in each template, and use CSS
magic to do the rest.
I'm just thinking it would be nice for Django to have a better way to
do this built in...
-Jesse
On Oct 16, 8:12 pm, Steve Holden <[EMAIL PROTECTED]&
I'm guessing it's somewhat common (as usual, I think it's common
because I do it) to put several navigational links in a template that
is included from several other templates, e.g.:
Page 1
Page 2
...
Page N
But also, it's helpful to indicate where the user currently is in the
navigational hiera
The --with-handler idea for manage.py runserver sounds reasonable to
me.
I just wanted to clarify a couple of points.
> No, this isn't correct. You already have to specify which handler to
> run. You still have to do that exactly once in each case.
I meant that it requires one extra configurati
dinnick <[EMAIL PROTECTED]>
wrote:
> On Wed, 2008-10-15 at 18:59 -0700, Jesse Young wrote:
> > Hi Malcolm,
>
> > Thanks for explaining the rationale behind this. It'd certainly be
> > possible to do what we want by overriding handle_uncaught_exception in
> >
t; Did you try subclassing list (& overriding __iter__) for the ADMINS
> object?
>
> -rob
>
> On Oct 15, 1:58 pm, Jesse Young <[EMAIL PROTECTED]> wrote:
>
> > The built-in behavior for
> > django.core.handlers.base.handle_uncaught_exception calls mail_admins
er. So subclassing the
handler seems like a rather high barrier to entry.
-Jesse
On Oct 15, 6:15 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Wed, 2008-10-15 at 13:58 -0700, Jesse Young wrote:
> > The built-in behavior for
> > django.core.handlers.base.handle_
k" <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2008 at 3:58 PM, Jesse Young <[EMAIL PROTECTED]> wrote:
>
> ...
>
>
>
> > I was thinking it would be useful to add a setting like
> > EXCEPTION_NOTIFIER = 'path.to.custom.notifier' , where the default
>
One thing I noticed while running some performance profiling tests a
while ago was that
django.db.models.fields.related._get_related_query_name was being
called approximately a zillion times, as was _curried from
django.utils.functional.
Although _get_related_query_name is very simple (return
sel
The built-in behavior for
django.core.handlers.base.handle_uncaught_exception calls mail_admins
for each internal server error.
So if a very high-traffic view has an internal server error, duplicate
emails will be sent at a very high rate. This isn't usually
desirable...
We worked around this by
I think it would be useful to include a session backend with Django
that stores session data in the cache and falls back to the database
if the session isn't in the cache. It's trivial to write your own
(mine is about 30 lines of code), but it seems like such a common use
case that it should just
Hey Alex,
On the trac ticket, I mentioned that my motivating reason for adding
specifying default-lazy fields in the Field definition (i.e., without
having to specify them on every query set) is the implicit queries
that Django creates for foreign key lookups (e.g., item =
obj.relateditem causes
> And LazyTextField could create the associated model behind the scenes,
> set up a descriptor for loading its contents only when necessary,
> cache those contents so they only get queried once, etc. And all this
> without a single patch to Django's core and without you having to
> manually mainta
Moving discussion from http://code.djangoproject.com/ticket/5420.
To summarize, I patched my local version of Django by adding a boolean
'lazy' parameter to the Field constructor, e.g.
models.TextField(lazy=True), which determines whether Django loads
that field by default on select queries, and
17 matches
Mail list logo
