> 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
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)
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
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
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
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
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.
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
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
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
13 matches
Mail list logo