Changes to Model does not migrate to sqlite with Django 1.7?

[Tobias Dacoir]

Hi,

I'm having trouble with changes to my Models. I just added a couple of new fields to my existing models but when I run manage makemigrations it says: No changes detected. When I try to log in to the admin panel it gives an operational error and says: No such column (because I added a column to my user model). I have tried to get rid of this error using google and various calls to makemigrations app_name or syncdb or whatever, but nothing helps. I always have to delete my sqlite database file and start with a new DB.

Is this a limitation of sqlite or some bug in Django?

[Daniel Roseman]

More likely to be something wrong with your code, unfortunately. This is explicitly the use case for migrations, and sqlite is a supported db, so it seems unlikely that it wouldn't work at all. You'll need to give more details, however: a set of repeatable steps starting from scratch, showing your initial models and migrations, the changes you made, the commands you ran, and the output.

--

DR.

[Markus Holtermann]

Hi Tobias,

can you share the code for your old model and you new model along with the existing migrations for that app, please. Without some details it's hard to figure out what's happening.

/Markus

[Tobias Dacoir]

Ok, here is part of the User Model:

class User(AbstractBaseUser, PermissionsMixin):

    SEX = (
        ('m', 'male'),
        ('f', 'female')
    )

    RANG = (
        ('b', 'beginner'),
        ('e', 'expert'),
        ('m', 'master')
    )

    username = models.CharField(_('username'), max_length=30, unique=True,
                                help_text=_('Required. 30 characters or fewer. Letters, numbers and @/./+/-/_ characters'),
                                validators=[
                                    validators.RegexValidator(re.compile('^[\w.@+-]+$'), _('Enter a valid username.'), _('invalid'))
                                ])
    first_name = models.CharField(_('first name'), max_length=30, blank=True, null=True)
    last_name = models.CharField(_('last name'), max_length=30, blank=True, null=True)
    email = models.EmailField(_('email address'), max_length=255, unique=True)

    is_staff = models.BooleanField(_('staff status'), default=False,
                                   help_text=_('Designates whether the user can log into this admin site.'))

    is_active = models.BooleanField(_('active'), default=True,
                                    help_text=_('Designates whether this user should be treated as active. Unselect this instead of deleting accounts.'))
    date_joined = models.DateTimeField(_('date joined'), default=timezone.now)
    expires = models.DateTimeField(_('expiration date'), default=one_year_from_now)

    age = models.IntegerField(blank=True, null=True)
    sex = models.CharField(max_length=1, choices=SEX, blank=True)
    native_language = models.CharField(max_length=200, blank=True)
    english_proficiency = models.CharField(max_length=100, blank=True)
    audio_device = models.CharField(max_length=200, blank=True)
    autoplay_enabled = models.BooleanField(default=True)

    USERNAME_FIELD = 'username'
    REQUIRED_FIELDS = ['email', ]

    objects = UserManager()

    class Meta:
        verbose_name = _('user')
        verbose_name_plural = _('users')

    def get_full_name(self):
        full_name = '%s %s' % (self.first_name, self.last_name)
        return full_name.strip()

    def get_short_name(self):
        return self.first_name

    """
    def is_active(self):
        return timezone.now() <= self.expires
    """

    def email_user(self, subject, message, from_email=None):
        send_mail(subject, message, from_email, [self.email])

(I removed some unrelated fields).
Now what I did was add the autoplay_enabled feature yesterday which wasn't there before. After adding this field, I saved the models.py ran manage.py makemigrations (no changes detected) and then still tried to run manage.py migrate.
After starting the server when I tried to log into the Admin panel with the Admin user (the DB was already populated by the Admin user, two more users and other stuff) it gave me an OperationalError: column autoplay_enabled does not exist.

This happened to me a lot of times when I added new fields to any of the models. I ended up writing a script that pre-populates the DB for me but I still have to manually delete my sqlite file, run migrations or syncdb and then create the superuser again.

So what am I doing wrong? I'm sure it's just my fault. At first I even manually edited the migrations file in the past, for example when I changed one of the fields to be mandatory instead of being optional. Old data in the database had this field still set to null, and sometimes Django asked me what to do with it but most of the time I never got it to work correctly - so again delete DB and repeat.

[James Schneider]

I have to wonder if the name of your class is causing an overlap with the Django contrib model, which may be causing confusion with the migrations process and not catching changes (since the core contrib version doesn't have any changes).

Would it be possible to change the name of the class, even for testing?

--
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...@googlegroups.com.
To post to this group, send email to django...@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/01706dc6-ea01-4d1d-ab3a-692f17435ddc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Schneider]

You can also temporarily remove django.contrib.auth from INSTALLED_APPS when making your migrations to keep the overlap from occurring as a test, although I'm not sure if that would be possible if any other code references the contrib User model and probably isn't recommended as a production deployment strategy.

-James

[Markus Holtermann]

A model is always uniquely identified by its app label and model name. Since migrations use that I don't see a way how this could happen. If you have two apps with the same app label the AppRegistry will blow up (and prevents Django from starting).

[Tobias Dacoir]

Well, I did follow some best-practice guides and even asked here on the forums on how to model my User class. I want the users to be able to use their username or email as login, and going with this inheriting from AbstractBaseUser and PermissionsMixin is what I was told. Maybe this doesn't work for 1.7 anymore?

[Markus Holtermann]

I tried to reproduce the problem with the steps you explained, but it works fine for me. Can you post your existing migration files for that app too, please. This will then hopefully give us some hints to solve your problem.

[Daniel Roseman]

On Monday, 8 December 2014 11:07:11 UTC, Tobias Dacoir wrote:

 

So what am I doing wrong? I'm sure it's just my fault. At first I even manually edited the migrations file in the past, for example when I changed one of the fields to be mandatory instead of being optional. Old data in the database had this field still set to null, and sometimes Django asked me what to do with it but most of the time I never got it to work correctly - so again delete DB and repeat.

Possibly a silly question, but are you sure you have the app containing this model in settings.INSTALLED_APPS?

--

DR. 

[Collin Anderson]

Hi,

Another silly question: have you made the initial migration(s) for your app yet?

Collin

[Tobias Dacoir]

Yes of course. Like I said, when I run into this error I have to delete my database file and do a fresh migration anyway.

[Tobias Dacoir]

Hi,

I'm afraid I don't have them. Apparently after deleting my database file and then just running manage.py makemigrations, it deleted the old migration files and started anew. Right now I'm also unable to re-produce it on purpose :( But it happened a couple of times for me since I regularly make multiple changes to my model (I'm still at the beginning of development) but if I just add a single new field now it works as expected.

Maybe sometimes Django can't detect changes to my file because I store my project in my dropbox folder and maybe this might be messing it up?

[Collin Anderson]

Hi,

Storing your files in dropbox _should_ be fine, unless it's a problem with *.pyc or __pycache__ files.

Collin