Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#23215 closed Bug (needsinfo)

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

Reported by: Eduardo Klein Owned by: nobody
Component: Database layer (models, ORM) Version: 1.7-rc-2
Severity: Normal Keywords: model default value
Cc: cmawebsite@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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(
    file = models.FileField()
    #some other fields

At some point of my code, I do:

image = Image()
..., file_content)

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.

Change History (8)

comment:1 Changed 4 years ago by Tim Graham

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

comment:2 Changed 4 years ago by 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 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?

Last edited 4 years ago by Collin Anderson (previous) (diff)

comment:3 Changed 4 years ago by Collin Anderson

Cc: cmawebsite@… added

comment:4 Changed 4 years ago by Eduardo Klein

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.

comment:5 Changed 4 years ago by Alexander

Simply mysqldump and restore your database from dump.

comment:6 Changed 4 years ago by 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.

comment:7 Changed 4 years ago by Tim Graham

Resolution: needsinfo
Status: newclosed

comment:8 Changed 4 years ago by Eduardo Klein

Sorry for the delay in responding.

I could not reproduce the issue, but the solution I used is described here:
I found a ticket in south that may be related:
Maybe, django's migrations behave the same way

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