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 [email protected]. To post to this group, send email to [email protected]. 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.
