Since you have already created the table using syncdb, you need to instruct
South to fake the initial migration. Try the command ./manage.py migrate
auth --fake and see if that works. You only need to run this once and then
all future migrations don't need the --fake flag.
Cheers,
Nick
On Tue, Jan 8, 2013 at 9:21 AM, galgal <weglarek.rob...@gmail.com> wrote:
> I try to use new User model. I made my custom model, attached it
> by: AUTH_USER_MODEL = 'account.Account'
> Model:
>
> class Account(AbstractBaseUser, PermissionsMixin):
> email = models.EmailField(
> verbose_name=_('email address'),
> max_length=255,
> unique=True,
> db_index=True,
> )
> username = models.CharField(
> _('username'),
> max_length=75,
> unique=True,
> help_text=_('Required. 75 characters or fewer. Letters, numbers
> and @/./+/-/_ characters'),
> validators=[
> validators.RegexValidator(re.compile('^[\w.@+-]+$'), _('Enter
> a valid username.'),
> 'invalid')
> ])
> is_staff = models.BooleanField(
> _('staff status'), default=False,
> help_text=_('Designates whether the user can log into this admin
> site.'))
> is_active = models.BooleanField(default=True)
> is_admin = models.BooleanField(default=False)
> date_joined = models.DateTimeField(_('date joined'),
> default=timezone.now)
>
> objects = AccountManager()
>
> USERNAME_FIELD = 'email'
> REQUIRED_FIELDS = ['username']
>
> def get_full_name(self):
> # The user is identified by their email address
> return self.email
>
> def get_short_name(self):
> # The user is identified by their email address
> return self.email
>
> def __unicode__(self):
> return self.email
>
>
> I can't sync my DB, when south is added. When I turn South off, run
> syncdb, all is ok. Then when I turn South on and try to make migrate, I
> get:
>
> ./manage.py migrate
>> Running migrations for auth:
>> - Migrating forwards to 0001_initial.
>> > auth:0001_initial
>> FATAL ERROR - The following SQL query failed: CREATE TABLE
>> `auth_permission` (`id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `name`
>> varchar(50) NOT NULL, `content_type_id` integer NOT NULL, `codename`
>> varchar(100) NOT NULL);
>> The error was: (1050, "Table 'auth_permission' already exists")
>> ! Error found during real run of migration! Aborting.
>> ! Since you have a database that does not support running
>> ! schema-altering statements in transactions, we have had
>> ! to leave it in an interim state between migrations.
>> ! You *might* be able to recover with: - no dry run output for
>> delete_unique_column() due to dynamic DDL, sorry
>> = DROP TABLE `auth_permission` CASCADE; []
>> = DROP TABLE `auth_group` CASCADE; []
>> = DROP TABLE `auth_group_permissions` CASCADE; []
>> = DROP TABLE `auth_user` CASCADE; []
>> = DROP TABLE `auth_user_groups` CASCADE; []
>> = DROP TABLE `auth_user_user_permissions` CASCADE; []
>> ! The South developers regret this has happened, and would
>> ! like to gently persuade you to consider a slightly
>> ! easier-to-deal-with DBMS (one that supports DDL transactions)
>> ! NOTE: The error which caused the migration to fail is further up.
>> Error in migration: auth:0001_initial
>> DatabaseError: (1050, "Table 'auth_permission' already exists")
>>
>> Any ideas what do I do wrong?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/WR_xxyrJGusJ.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
