Thanks!
Ok, I see that the problem is more complicated than I thought, so I'll
leave it that way.
I just want to add that if you decide that you don't like the current
behaviour, you can always use FutureWarning, to first warn if a value
was set and is about to be discarded, and then change the
On 7/5/07, Noam <[EMAIL PROTECTED]> wrote:
>
> The conclusion is that auto_now_add should set the date only if it is
> None. Or, another solution: it should set the date upon instance
> creation, not upon saving.
FYI - this is a known problem, with scope and ramifications much
larger than the
On Thu, 2007-07-05 at 10:52 +0300, Noam Raphael wrote:
> On 7/5/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> > It's a backwards-incompatible change, so we'd need a strong reason to
> > change it.
> [...]
> > This line of reasoning is unfortunately not particularly strong. The
> >
Hello,
The question is, as I see it, what bad thing would happen if
auto_now_add would set the date only if it's None. I think that
nothing bad would happen - why should someone manually set the date
and expect it to be overwritten? If you agree, I suggest that it will
be changed, because I
If your using auto_now_add, then you should want the date
auto-populated *every* time. If that is not the behavior you want,
then writing you own save method can easily give you the behavior you
want.
Actually, in your case, you probably want auto_now_add's behavior all
the time. That is with
Hello,
I wrote a script to convert from an old database (turbogears) to
django. It involved a few loops like this:
for oldm in messages:
newm = models.Message()
newm.date = oldm.date
newm.text = oldm.text
newm.save()
After running the script, I discovered
