This seems to be a common point of confusion. I'll add a sentence to release notes under the "``AbstractUser.last_login`` allows null values" section -- if this makes sense:
If you are using a custom user model, you'll need to run :djadmin:`makemigrations` and generate a migration for your app. On Tuesday, April 21, 2015 at 12:27:57 PM UTC-4, aRkadeFR wrote: > > Hello, > > I'm upgrading my systems to Django 1.8 and I'm facing this error: > (1048, "Column 'last_login' cannot be null") > > so I describe my table in DB: > +---------------------+------------------+------+-----+---------+----------------+ > > > | Field | Type | Null | Key | Default | > Extra | > +---------------------+------------------+------+-----+---------+----------------+ > > > | last_login | datetime | NO | | NULL > | | > > > and yep, it is not nullable, but the 0005_alter_user_last_login_null > migrations > is run, so why this field is not nullable? > How can I debug this? > > PS: I run ./manage.py migrate (without --fake option) > and I use the AbstractUser as my base class. > > Thanks and have a good one > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/cb08163e-c638-4736-aad9-5dd1dc89e44c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
