Saving the model in Django gives me "Warning: Field 'id' does not have a default value"

Question

I have a very simple model in Django:

class Case(models.Model): name = models.CharField(max_length=255) created_at = models.DateTimeField(default=datetime.now) updated_at = models.DateTimeField(default=datetime.now) def save(self): if self.created_at == None: self.created_at = datetime.now() self.updated_at = datetime.now() super(Case, self).save() class Meta: db_table = u'cases' 

Since I did not specify a PC, Django took care of this for me. I see a field in my database called "id" that is marked as primary key and auto-increment. I find it strange that I get this warning, because everything is fine over the database and the end of the model. Error:

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

My job when saving is to set id to 0. It kills the warning, and the identifier is set correctly, since MySQL handles it.

 case = Case() case.id = 0 #ugly workaround for - Warning: Field 'id' doesn't have a default value case.name = request.POST[u'case[name]'] case.save() 

The problem with this solution is:

• It's not beautiful
• The new PK is not available after saving, which makes it impossible to serialize correctly

Does anyone know how to fix this?

I run:

 Python 2.7.2 django.VERSION (1, 3, 1, 'final', 0) mysql Ver 14.14 Distrib 5.1.45, for apple-darwin10.2.0 (i386) using readline 5.1 MySQL_python-1.2.3-py2.7-macosx-10.4-x86_64.egg 

And my creation table looks like this:

 CREATE TABLE `cases` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, `created_at` datetime NOT NULL, `updated_at` datetime NOT NULL, PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=45 DEFAULT CHARSET=latin1 

Answer 1

I would like to expand on this question since this week I came across this. I was getting the exact same error and looked at the model definition, and the SQL definition showed that:

• Models affected either did not have a pronounced PK, or had a pronounced PK (both had problems). This in itself seemed disconnected.

• The affected tables had a definition of "id", as in the OP, i.e. id int(11) NOT NULL AUTO_INCREMENT . PRIMARY KEY set as expected.

• Looking into the MySQL query log, I got something like this:

   INSERT INTO `x` (...) VALUES (...) SHOW WARNINGS ROLLBACK 

  The request is individually executed successfully, and SHOW WARNINGS reflects the warning indicated in the OP.

However, I came across a MySQL-based fix, http://webit.ca/2012/01/field-id-doesnt-have-a-default-value/ mentioned that resetting the identifier definition (which, at a quick glance, seems to , no different) problem. I can’t explain why this works, but it solves the problem without any additional code changes. I believe that this may be somehow related to deleting records, but the whole problem seems insensitive to me.

Answer 2

Do you have the opportunity to recreate the database? Something seems to be wrong with him.

As an additional note: you do not need to call datetime.now() on created_at if you have already set the default for the datetime.now field.

Answer 3

Your save method is not really needed, you can use the arguments: DateField.auto_now and DateField.auto_now_add . These arguments handle your created_at and updated_at attributes:

• DateField.auto_now : automatically set the field now every time an object is saved. Useful for timestamps with the latest change.
• DateField.auto_now_add : automatically set the field when the object is first created. Useful for creating timestamps.

Try using the default save () method again, hoping this helps!

Read more about auto_now and auto_now_add at: https://docs.djangoproject.com/en/dev/ref/models/fields/#datefield

Answer 4

The save method sometimes uses extra arguments and keywors arguments, but you don't handle them. I'm not sure, but this may solve your problem.

 def save(self, *args, **kwargs): if self.created_at == None: self.created_at = datetime.now() self.updated_at = datetime.now() super(Case, self).save(*args, **kwargs) 

Answer 5

I fixed this by filtering out the warning:

 import warnings warnings.filterwarnings("ignore", "Field 'id' doesn't have a default value") 

Saving and serializing now looks good

Answer 6

I'm sure you probably fixed the problem so far, but I just ran into the same problem.

Turns off auto-increment was not set for the primary key, so I fixed the problem by turning on auto-increment for each primary key in my database.

Hope this helps someone else who gets the same problem.

Answer 7

I have the same problem too, when I look into the mysql structure, the 'id' field is not the first field. I changed the structure so that it will apperar as the first field, then my problem will be solved. But I still do not know the real problem.

SQL script before the problem is resolved for this table: CREATE A TABLE IF user_id DOES NOT EXIST marketing_sponseredhashtag ( user_id int (11) NOT NULL, start_date datetime NOT NULL, created datetime NOT NULL DEFAULT '2013-02-12 14:00:04' , modified datetime NOT NULL DEFAULT '2013-02-12 14:00:04', payment decimal (10,2) NOT NULL, paid tinyint (1) NOT NULL DEFAULT '0', status tinyint (1) NOT NULL DEFAULT ' 0 ', expiry_date datetime NOT NULL, id int (11) NOT NULL AUTO_INCREMENT, tag varchar (180) NOT NULL, PRIMARY KEY ( id ), KEY marketing_sponseredhashtag_403f60f ( user_id )) ENGINE = MyISAM DEFAULT CHARSET = latin1 AUTO_;

After release, the structure is fixed: CREATE A TABLE IF THERE IS NOT EXISTING marketing_sponseredhashtag ( id int (11) NOT NULL AUTO_INCREMENT, user_id int (11) NOT NULL, start_date datetime NOT NULL, created datetime NOT NULL DEFAULT '2013-02-12 14: 00:04 ', modified datetime NOT NULL DEFAULT' 2013-02-12 14:00:04 ', payment decimal (10,2) NOT NULL, paid tinyint (1) NOT NULL DEFAULT' 0 ', status tinyint (1) NOT NULL DEFAULT '0', expiry_date datetime NOT NULL, tag varchar (180) NOT NULL, PRIMARY KEY ( id ), KEY marketing_sponseredhashtag_403f60f ( user_id )) ENGINE = MyISAM DEFAULT CHARSET = latin1 AUTO_INCREMENT = 4;

Answer 8

I had the same error when starting the migrations, and it turned out that I had to change the structure of the django tables by default: django_admin_log, django_content_type and django_migrations, since the primary key was set incorrectly (I don’t know why, maybe a bad migration to some moment)

I used the following query to update tables:

ALTER TABLE django_migrations MODIFY id INT (11) NOT NULL AUTO_INCREMENT;