Re: What is the status of auto_now and auto_now_add?

> By the way drossy, I still don't know why it's evil, just that every > respected Django dev (and BDFLs) were +1 on removing it (very +1). But > the reasons don't seem consistent. In one case James B. describe's > some unexplained side effects of using it (which coincide with another > bloggers

Session/cookie based messages (#4604)

In the spirit of Russell's No! Bad Pony! talk at DjangoCon I'd like to start a conversation about cleaning up session messages enough to get them into core or contrib. Alex suggested that the ticket (http:// code.djangoproject.com/ticket/4604) was not the right place for the conversation so I'm

Re: What is the status of auto_now and auto_now_add?

I find it amusing how people like to use fancy words like DRY, without explaining exactly how it applies. I am not trying to argue for keeping auto_now, but I just don't see what the fuss is about? The lazy date thing seems more "un-DRY" to me that this. But then again, why not have both? + the

Re: What is the status of auto_now and auto_now_add?

By the way drossy, I still don't know why it's evil, just that every respected Django dev (and BDFLs) were +1 on removing it (very +1). But the reasons don't seem consistent. In one case James B. describe's some unexplained side effects of using it (which coincide with another bloggers findings)

Re: CSRF proposal and patch ready for review

On Monday 31 August 2009 15:26:42 Russell Keith-Magee wrote: > 1. Is there anything we can do to fix the problems with the > ResponseMiddleware? I know there are problems, but at the core there > is something really good - it seems a waste to throw it all away. I just stumbled across a new

Re: What is the status of auto_now and auto_now_add?

Thank you Waylan for your comments. I've found the developer discussion about this (searching the group for "auto_now_add" does not find the result! wow! Google missing an easy hit?). http://groups.google.com/group/django-developers/browse_thread/thread/4cd631c225cb4e52 . This solves the problem

Re: What is the status of auto_now and auto_now_add?

On Thu, Sep 10, 2009 at 12:21 PM, drozzy wrote: > > Well, that is the purpose of that. I mean if you want a custom field > that saves only on Thursday, it makes sense to write a modified save > routine.. Of course it is the purpose. I was replying to Ryan K, with sort of an

Re: What is the status of auto_now and auto_now_add?

Well, that is the purpose of that. I mean if you want a custom field that saves only on Thursday, it makes sense to write a modified save routine.. On Sep 10, 1:19 pm, Andrew Gwozdziewycz wrote: > On Thu, Sep 10, 2009 at 9:35 AM, Ryan K wrote: > > I'm

Re: What is the status of auto_now and auto_now_add?

On Thu, Sep 10, 2009 at 9:35 AM, Ryan K wrote: > I'm trying to give advice to people but I can't even figure it out > myself (even though it works for me just fine -- so far?). Last week, I ran into a problem using them because I wanted to set manually the date in certain

Re: What is the status of auto_now and auto_now_add?

I see, but what strikes me as odd is the comment in the source: "#HACKs : auto_now_add/auto_now should be done as a default or a pre_save." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group.

Re: What is the status of auto_now and auto_now_add?

Well, both auto_now and auto_now_add are fully documented [1] and part of the official releases since 1.0. And I note that the docs specifically mention how auto_now_add behaves in the admin (remember the newforms-admin was merged before 1.0 was released). That being the case the devs have

Re: What is the status of auto_now and auto_now_add?

Hi, I've looked at the svn and I don't quite understand what's wrong with auto_now or auto_now_add. Can you see a problem with it? http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/__init__.py#L453 On Sep 10, 10:35 am, Ryan K wrote: > I wrote an

Re: Replacing get_absolute_url, I am against it

On Thu, Sep 10, 2009 at 11:23 AM, drozzy wrote: > > Just read the "Replacing get_absolute_url proposal": > http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl > > and personally I think adding two functions get_url_path and get_url > is a lot more confusing. One can

Replacing get_absolute_url, I am against it

Just read the "Replacing get_absolute_url proposal": http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl and personally I think adding two functions get_url_path and get_url is a lot more confusing. One can never remember which one gets the Absolute url and which one gets the Relative

Re: proper place to put startup code

On Thu, Sep 10, 2009 at 7:54 AM, Andrew Gwozdziewycz wrote: > > Sorry, I mistyped the email address; moving to django-users > > On Sep 10, 7:04 am, Andrew Gwozdziewycz wrote: >> Hello, >> >> What's the recommended place to put code that should be run once

Re: proper place to put startup code

Sorry, I mistyped the email address; moving to django-users On Sep 10, 7:04 am, Andrew Gwozdziewycz wrote: > Hello, > > What's the recommended place to put code that should be run once upon > application initialization? I'm currently doing something along the > lines of: > >  

What is the status of auto_now and auto_now_add?

I wrote an article here http://www.ryankaskel.com/2009/09/09/model-development-tips-for-django-projects/ describing a useful case (or rather a useful set up for many potential cases) using abstract base models that implements this: # Abstract models used by various application specific models

proper place to put startup code

Hello, What's the recommended place to put code that should be run once upon application initialization? I'm currently doing something along the lines of: 1. Create a new signal post_init 2. Connecting handlers to post_init in a file startup.py 3. Sending the signal at the top of a