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).
On Monday, December 8, 2014 12:15:30 PM UTC+1, James Schneider wrote:
>
> 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?
> On Dec 8, 2014 3:07 AM, "Tobias Dacoir" <fal...@gmail.com <javascript:>>
> wrote:
>
>> 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.
>>
>> --
>> 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 <javascript:>.
>> To post to this group, send email to django...@googlegroups.com
>> <javascript:>.
>> 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
>>
>> <https://groups.google.com/d/msgid/django-users/01706dc6-ea01-4d1d-ab3a-692f17435ddc%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
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/7859a15b-e52f-460f-b46b-4deebb1eec82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
