Default values of datetime.now now handled properly by ORM freezing

[sean.b.oconnor@…]

The startmigration command doesn't properly handle freezing DateTimeFields? with a default of datetime.now. Below is an example of what happens.

If I have a model such as the following:

from django.db import models
from datetime import datetime

class Event(models.Model):
    date = models.DateTimeField(default=datetime.now)

And I run the command:

./manage.py startmigration myapp do_something --freeze=myapp

I end up with a migration which contains something like:

models = {
    'myapp.event': {
         'date':  ('models.DateTimeField', [], {'default': 'datetime.datetime(2009, 5, 6, 15, 33, 15, 780013)'}),
     }
}

Running this new migration generates an error similar to:

ValueError: Cannot successfully create field 'date' for model 'event': type object 'datetime.datetime' has no attribute 'datetime'.

Changing the default value in the migration's model information from "datetime.datetime" to just "datetime" seems to fix the problem.

[sean.b.oconnor@…]

Forgot to mention in the initial report that this happens with the SVN version of South.

[andrew]

Ah, repr() fail. The entire decision to do this was somewhat unliked (see #132) in the first place, and while it's trivial to throw datetime into the context, it seems a bit like a special case...

I'll fix this special case soonish, however, things should work.

[jtauber]

Note that I just got this on 0.5 running ./manage.py startmigration foo bar --auto

see ​http://code.pinaxproject.com/paste/tWxY/

where model had created = models.DateTimeField?(default=datetime.now)

[andrew]

This should be fixed by [237]; I've decided not to evaluate functions as defaults after all.