On Sep 3, 4:06 pm, Russell Keith-Magee wrote:
> Adding non-SQL backends into the mix complicates things a little
> further, since a query could be directed at a non-SQL backend. Working
> out exactly how to handle this sort of eventuality is one of the
> things I want to look at during the sprint
> 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 f
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 s
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 "
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) w
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 argu
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 s
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 answer
of "it depends.
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 trying to give advice to people but I can't
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 situations. auto_now se
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.
To
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 committ
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 article
> herehttp://
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 never remember which on
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 url.
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 upon
>> application initialization?
I p
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:
>
> 1. Create a new s
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
f
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 mode
19 matches
Mail list logo
