Opened 13 months ago

Closed 13 months ago

Last modified 13 months ago

#22363 closed Bug (fixed)

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

Reported by: linovia Owned by: charettes
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 Changed 13 months ago by charettes

  • Needs documentation unset
  • Needs tests unset
  • Owner changed from linovia to charettes
  • Patch needs improvement unset
  • Severity changed from Normal to Release blocker
  • Status changed from new to assigned
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 13 months ago by charettes

Created a PR with a fix.

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

comment:3 Changed 13 months ago by linovia

I just gave it a try and it works. Thanks for the PR.

Last edited 13 months ago by linovia (previous) (diff)

comment:4 Changed 13 months ago by melinath

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 Changed 13 months ago by charettes

  • Summary changed from namespace issues with date when used as default value to User provided one-off default date and datetime are not correctly serialized

Adjusted the ticket summary to reflect the actual issue.

comment:6 Changed 13 months ago by timo

  • Triage Stage changed from Accepted to Ready for checkin

comment:7 Changed 13 months ago by Simon Charette <charette.s@…>

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

In 074d3183d92cd5ed5da8f51e7048b12a96f55e0a:

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

Thanks to linovia for the report.

comment:8 Changed 13 months ago by Simon Charette <charette.s@…>

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