Warning: Field 'id' doesn't have a default value

[Eduardo Klein]

This is a problem that I don't have with django 1.7.b4, but I do have it with 1.7c2.

I have a model like this:

class Image(models.Model):
    id = models.AutoField(primary_key=True)
    datetime = models.DateTimeField(default=datetime.now)
    file = models.FileField()
    #some other fields

At some point of my code, I do:

image = Image()
...
image.file.save(filename, file_content)
image.save()

This works fine with django 1.7.b4, but gives the following error (even if it says warning):
"Field 'id' doesn't have a default value"

My db backend is MySQL.

This seems to be a bug, since I did not find anything in the release notes that says that this was not possible in django 1.7

I have tried to create a test model to reproduce the problem, but all the tests I made with the 3 fields above only passed (no errors). There must be some specific condition in my model that makes it fails.

Since you know what has changed from 1.7.b4 to 1.7c2, do yoy know or have an idea of what maybe happening. If you give me directions on what have changed, I can make more tests to reproduce the bug.

[Tim Graham]

No ideas, you could try bisecting to find the commit that introduced the change. What code is triggering the warning?

[Collin Anderson]

Is your id field actually auto_increment in the database? Did you create the id field first, then switch it to an AutoField later?

run python manage.py dbshell then show columns in nameofyourapp_image; and see if it has auto_increment next to the id field under Extra.

Are you using migrations?

[Eduardo Klein]

Hi,
My id has the autoincrement as well. Here is the output.
Field | Type | Null | Key | Default | Extra |
+-----+--------------+------+-----+---------+----------------+
| id | int(11)| NO | PRI | NULL | auto_increment

But you may have given a hint to the issue. When I first created the model, I did not declare the id field in it, so django has created it automatically. Then, later on, I added it and ran the migrate, that obviously did not change the db.

I'm going to debug more and try to find the cause. I'll try bisecting it (although never used before).

I'll post my findings as soon as I have something interesting.

[Alexander]

Simply mysqldump and restore your database from dump.

[RoninDusette]

Any time you make a change to your models, like say, adding/changing a field that is required, you HAVE to give it a default value.

Think about it. If null=True and blank=True are not set on that field, django will not want to save it to the DB, and it will require a non-NULL piece of data to hold in there.

When I ran across this, it scared me, so what I did was just add blank=True and null=True to those specific fields, and then I would have to do a little work to bring the existing tables up-to-date with it, then I would go remove blank/null=True on that field, sync it up, before ANY new entries are made. After that it should be good. This is not a programming issue nor a bug. It is more of a lack of experience doing migrations.

As BlindHunter said, you should just revert your changes to your models and restore your database from backup.... You DO use Git or something for your code, and you DID backup your database, didn't you? :D If not, this is a good experience to learn from. haha.

Also, don't add an ID field. Django creates and auto-incrementing ID field for you already.

[Eduardo Klein]

Sorry for the delay in responding.

I could not reproduce the issue, but the solution I used is described here: ​http://webit.ca/2012/01/field-id-doesnt-have-a-default-value/
I found a ticket in south that may be related: ​http://south.aeracode.org/ticket/1160
Maybe, django's migrations behave the same way