Ticket #135 (closed defect: fixed)

Opened 7 years ago

Last modified 16 months ago

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

Reported by: sean.b.oconnor@… Owned by: andrew
Priority: minor Milestone: 0.6
Component: migrations Version: 0.6-pre
Keywords: Cc:


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.

Change History

comment:1 Changed 7 years ago by sean.b.oconnor@…

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

comment:2 Changed 7 years ago by andrew

  • Status changed from new to assigned
  • Version set to subversion
  • Milestone set to 0.6

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.

comment:3 Changed 7 years ago by 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)

comment:4 Changed 7 years ago by andrew

  • Status changed from assigned to closed
  • Resolution set to fixed

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

Note: See TracTickets for help on using tickets.