> I can't see the problem in that article.
> Also, the datetime objects have changed since then, taking a timezone
> as optional parameter:
> http://docs.python.org/library/datetime.html#datetime-objects
>
> I mean we are using date/time already with our pre-save way of doing
> things, why should
I can't see the problem in that article.
Also, the datetime objects have changed since then, taking a timezone
as optional parameter:
http://docs.python.org/library/datetime.html#datetime-objects
I mean we are using date/time already with our pre-save way of doing
things, why should auto_add act
> 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
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
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://
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
13 matches
Mail list logo