Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Migration DBError 1061 Duplicate key name 'social_auth_nonce-67...' with v0.7.20 #612

Closed
topiaruss opened this Issue Feb 20, 2013 · 11 comments

Comments

Projects
None yet
2 participants
Contributor

topiaruss commented Feb 20, 2013

Hello all.

I upgraded to v0.7.20, and see the following error on testing (which installs a fresh test db, then migrates) or when trying to migrate my local devel database, once I delete the south entries for DSA, and drop the tables.

Same on South 0.7.4 and 0.7.6
MySQL 5.5.29-0ubuntu0.12.10.1

- Migrating forwards to 0002_auto__add_unique_nonce_timestamp_salt_server_url__add_unique_associati.
  
  > social_auth:0001_initial
  > social_auth:0002_auto__add_unique_nonce_timestamp_salt_server_url__add_unique_associati
  > FATAL ERROR - The following SQL query failed: CREATE INDEX `social_auth_nonce_67f1b7ce` ON `social_auth_nonce` (`timestamp`);
  > The error was: (1061, "Duplicate key name 'social_auth_nonce_67f1b7ce'")
  > ! 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 INDEX `social_auth_association_5a32b972` ON `social_auth_association` []
- no dry run output for delete_unique_column() due to dynamic DDL, sorry
  = DROP INDEX `social_auth_nonce_67f1b7ce` ON `social_auth_nonce` []
  
  ! 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: social_auth:0002_auto__add_unique_nonce_timestamp_salt_server_url__add_unique_associati
  Traceback (most recent call last):
  File "manage.py", line 17, in <module>
    execute_manager(settings)
  File "/home/russ/scraft/local/lib/python2.7/site-packages/django/core/management/**init**.py", line 459, in execute_manager
    utility.execute()
  File "/home/russ/scraft/local/lib/python2.7/site-packages/django/core/management/**init**.py", line 382, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/russ/scraft/local/lib/python2.7/site-packages/django/core/management/base.py", line 196, in run_from_argv
    self.execute(_args, *_options.**dict**)
  File "/home/russ/scraft/local/lib/python2.7/site-packages/django/core/management/base.py", line 232, in execute
    output = self.handle(_args, *_options)
  File "/home/russ/scraft/local/lib/python2.7/site-packages/south/management/commands/migrate.py", line 108, in handle
    ignore_ghosts = ignore_ghosts,
  File "/home/russ/scraft/local/lib/python2.7/site-packages/south/migration/**init**.py", line 213, in migrate_app
    success = migrator.migrate_many(target, workplan, database)
  File "/home/russ/scraft/local/lib/python2.7/site-packages/south/migration/migrators.py", line 235, in migrate_many
    result = migrator.**class**.migrate_many(migrator, target, migrations, database)
  File "/home/russ/scraft/local/lib/python2.7/site-packages/south/migration/migrators.py", line 310, in migrate_many
    result = self.migrate(migration, database)
  File "/home/russ/scraft/local/lib/python2.7/site-packages/south/migration/migrators.py", line 133, in migrate
    result = self.run(migration)
  File "/home/russ/scraft/local/lib/python2.7/site-packages/south/migration/migrators.py", line 107, in run
    return self.run_migration(migration)
  File "/home/russ/scraft/local/lib/python2.7/site-packages/south/migration/migrators.py", line 81, in run_migration
    migration_function()
  File "/home/russ/scraft/local/lib/python2.7/site-packages/south/migration/migrators.py", line 57, in <lambda>
    return (lambda: direction(orm))
  File "/home/russ/scraft/src/django-social-auth/social_auth/migrations/0002_auto__add_unique_nonce_timestamp_salt_server_url__add_unique_associati.py", line 10, in forwards
    db.create_index(Nonce._meta.db_table, ['timestamp'])
  File "/home/russ/scraft/local/lib/python2.7/site-packages/south/db/generic.py", line 44, in _cache_clear
    return func(self, table, _args, *_opts)
  File "/home/russ/scraft/local/lib/python2.7/site-packages/south/db/generic.py", line 860, in create_index
    self.execute(sql)
  File "/home/russ/scraft/local/lib/python2.7/site-packages/south/db/generic.py", line 273, in execute
    cursor.execute(sql, params)
  File "/home/russ/scraft/local/lib/python2.7/site-packages/django/db/backends/util.py", line 40, in execute
    return self.cursor.execute(sql, params)
  File "/home/russ/scraft/local/lib/python2.7/site-packages/django/db/backends/mysql/base.py", line 114, in execute
    return self.cursor.execute(query, args)
  File "/home/russ/scraft/local/lib/python2.7/site-packages/MySQLdb/cursors.py", line 174, in execute
    self.errorhandler(self, exc, value)
  File "/home/russ/scraft/local/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
    raise errorclass, errorvalue
  django.db.utils.DatabaseError: (1061, "Duplicate key name 'social_auth_nonce_67f1b7ce'")

Contributor

topiaruss commented Feb 20, 2013

I've reverted to putting my email__iexact change onto the v0.7.19 tag, and that's working fine for me. There were big changes between 19 and 20 in the migration scripts, and it seems that something is getting done twice, creating the Duplicate Index. So this is what I'm using at the moment: https://github.com/Sponsorcraft/django-social-auth/tree/v0.7.19a

Owner

omab commented Feb 22, 2013

@topiaruss, there were some changes but the final result is the same (the changes were to avoid some issues when custom user models were used). If the key is already in place but the migration wasn't applied, try running it with --fake argument.

Contributor

topiaruss commented Feb 22, 2013

Hi Mattias,

I agree that the final result should the same, but I'm getting the error that I pointed out, in any case.
If I run with --fake, then I will not have the social auth tables in place.

I need that migration script to run every time tests run, and recreate the database, otherwise I have no table to work with. When I stepped back to 0.7.19, it runs exactly the way it always did. with 0.7.20 there seems to be a second attempt to create the index, which causes the error, leaving the south migration pointer set at 0001_initial. Just to make that clear, this error occurs after dropping the database, and running a test.

Owner

omab commented Feb 22, 2013

@topiaruss, thanks, I'll take a look to migrations and make them backward compatible.

Contributor

topiaruss commented Feb 22, 2013

Thanks so much.

If you are testing against MySQL you should see the same problem.

--r.
On 22 Feb 2013, at 17:59, Matías Aguirre notifications@github.com wrote:

@topiaruss, thanks, I'll take a look to migrations and make them backward compatible.


Reply to this email directly or view it on GitHub.

Russ Ferriday -- Software and Systems Architect/Developer
CEO Topia Systems Ltd.
russf@topia.com -- +44 7429 518822 -- www.topia.com

@ghost

ghost commented Feb 22, 2013

This migration try create indexes which already exists. Just remove 10 and 13 lines or manually remove indexes after first migration in database via PhpPostgreAdmin, for example and try again.

https://github.com/omab/django-social-auth/blob/master/social_auth/migrations/0002_auto__add_unique_nonce_timestamp_salt_server_url__add_unique_associati.py

@ghost

ghost commented Feb 22, 2013

With --fake option you may lose creation of unique indexes (don't forget to add them manually).

Contributor

topiaruss commented Feb 22, 2013

Thanks lorddaedra.

The point of the migration is that I can go from an EMPTY database for each test run.That's what I am doing when I encounter the error. I cannot live with a solution that requires --fake, or resolution of these things by hand.

I have not had chance to look at the details, but 0.7.19 works fine. .20 fails.

Owner

omab commented Feb 22, 2013

@topiaruss is right, the migration shouldn't fail, I didn't had time to investigate this yet, meanwhile @topiaruss, could you post the process you are following to reproduce it?

Contributor

topiaruss commented Feb 23, 2013

It's a very normal process.
I'm running on MySQL. I update to .20, run my tests. During test db initialization and migration, I get the traceback above. I think you'll hit the same problem the first time you try a migration against mySQL.

Owner

omab commented Mar 4, 2013

@topiaruss, by merging #593, this issue is fixed, please take a look. Reopen if needed.

@omab omab closed this Mar 4, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment