Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#22363 closed Bug (fixed)

User provided one-off default date and datetime are not correctly serialized

Reported by: linovia Owned by: Simon Charette
Component: Migrations Version: 1.7-beta-1
Severity: Release blocker Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

While playing with Django 1.7 I noticed there was an issue with some generated migrations.

I had a model to which I added:

some_date = models.DateField()

I ran the makemigration and it prompted me to enter a default value:

$ python manage.py makemigrations 
You are trying to add a non-nullable field 'some_date' to post without a default;
we can't do that (the database needs something to populate existing rows).
Please select a fix:
 1) Provide a one-off default now (will be set on all existing rows)
 2) Quit, and let me add a default in models.py
Select an option: 1
Please enter the default value now, as valid Python
The datetime module is available, so you can do e.g. datetime.date.today()
>>> datetime.date.today()
Migrations for 'blog':
  0006_post_some_date.py:
    - Add field some_date to post

It created the following migration:

# encoding: utf8
from django.db import models, migrations
import datetime


class Migration(migrations.Migration):

    dependencies = [
        ('blog', '0005_post_image_big'),
    ]

    operations = [
        migrations.AddField(
            model_name='post',
            name='some_date',
            field=models.DateField(default=date(2014, 3, 31)),
            preserve_default=False,
        ),
    ]

Now if you look at the default, it uses date(...) while it only imports datetime and thus will not be able to run.

Change History (8)

comment:1 by Simon Charette, 11 years ago

Owner: changed from linovia to Simon Charette
Severity: NormalRelease blocker
Status: newassigned
Triage Stage: UnreviewedAccepted

comment:2 by Simon Charette, 11 years ago

Created a PR with a fix.

Could you confirm re-creating a the faulty migration with the applied patch solves your issue?

comment:3 by linovia, 11 years ago

I just gave it a try and it works.

Version 0, edited 11 years ago by linovia (next)

comment:4 by Stephen Burrows, 11 years ago

I just ran into this issue as well. I wouldn't call it a namespacing problem, though... the generated migration is just leaving off the datetime module name when trying to set datetime defaults.

comment:5 by Simon Charette, 11 years ago

Summary: namespace issues with date when used as default valueUser provided one-off default date and datetime are not correctly serialized

Adjusted the ticket summary to reflect the actual issue.

comment:6 by Tim Graham, 11 years ago

Triage Stage: AcceptedReady for checkin

comment:7 by Simon Charette <charette.s@…>, 11 years ago

Resolution: fixed
Status: assignedclosed

In 074d3183d92cd5ed5da8f51e7048b12a96f55e0a:

Fixed #22363 -- Correctly serialize django.utils.datetime_safe objects.

Thanks to linovia for the report.

comment:8 by Simon Charette <charette.s@…>, 11 years ago

In 7b3a221ad674ce74afd5db2a7dd0a0a3beb354ed:

[1.7.x] Fixed #22363 -- Correctly serialize django.utils.datetime_safe objects.

Thanks to linovia for the report.

Backport of 074d3183d9 from master

Note: See TracTickets for help on using tickets.
Back to Top