After changed latin1_swedish_ci to utf8_general_ci can't migrate db

问题

Yesterday I deleted my db tables, cause I needed change latin1_swedish_ci to utf8_general_ci for have a polish words in my apps. After that i can't do full migrate my database, because I have problem like that:

    (venv) C:\netbast\fastandbeauty\project>manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, comments, contenttypes, registration, sessions, social_django, user_content, user_profile
Running migrations:
  Applying social_django.0005_auto_20160727_2333...Traceback (most recent call last):
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\db\backends\utils.py", line 65, in execute
    return self.cursor.execute(sql, params)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\db\backends\mysql\base.py", line 101, in execute
    return self.cursor.execute(query, args)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\MySQLdb\cursors.py", line 250, in execute
    self.errorhandler(self, exc, value)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\MySQLdb\connections.py", line 50, in defaulterrorhandler
    raise errorvalue
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\MySQLdb\cursors.py", line 247, in execute
    res = self._query(query)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\MySQLdb\cursors.py", line 411, in _query
    rowcount = self._do_query(q)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\MySQLdb\cursors.py", line 374, in _do_query
    db.query(q)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\MySQLdb\connections.py", line 292, in query
    _mysql.connection.query(self, query)
_mysql_exceptions.OperationalError: (1071, 'Specified key was too long; max key length is 1000 bytes')

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "C:\netbast\fastandbeauty\project\manage.py", line 22, in <module>
    execute_from_command_line(sys.argv)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\core\management\__init__.py", line 363, in execute_from_command_line
    utility.execute()
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\core\management\__init__.py", line 355, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\core\management\base.py", line 283, in run_from_argv
    self.execute(*args, **cmd_options)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\core\management\base.py", line 330, in execute
    output = self.handle(*args, **options)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\core\management\commands\migrate.py", line 204, in handle
    fake_initial=fake_initial,
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\db\migrations\executor.py", line 115, in migrate
    state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\db\migrations\executor.py", line 145, in _migrate_all_forwards
    state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\db\migrations\executor.py", line 244, in apply_migration
    state = migration.apply(state, schema_editor)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\db\migrations\migration.py", line 129, in apply
    operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\db\migrations\operations\models.py", line 536, in database_forwards
    getattr(new_model._meta, self.option_name, set()),
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\db\backends\base\schema.py", line 353, in alter_unique_together
    self.execute(self._create_unique_sql(model, columns))
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\db\backends\base\schema.py", line 120, in execute
    cursor.execute(sql, params)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\db\backends\utils.py", line 80, in execute
    return super(CursorDebugWrapper, self).execute(sql, params)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\db\backends\utils.py", line 65, in execute
    return self.cursor.execute(sql, params)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\db\utils.py", line 94, in __exit__
    six.reraise(dj_exc_type, dj_exc_value, traceback)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\utils\six.py", line 685, in reraise
    raise value.with_traceback(tb)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\db\backends\utils.py", line 65, in execute
    return self.cursor.execute(sql, params)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\django\db\backends\mysql\base.py", line 101, in execute
    return self.cursor.execute(query, args)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\MySQLdb\cursors.py", line 250, in execute
    self.errorhandler(self, exc, value)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\MySQLdb\connections.py", line 50, in defaulterrorhandler
    raise errorvalue
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\MySQLdb\cursors.py", line 247, in execute
    res = self._query(query)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\MySQLdb\cursors.py", line 411, in _query
    rowcount = self._do_query(q)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\MySQLdb\cursors.py", line 374, in _do_query
    db.query(q)
  File "C:\netbast\fastandbeauty\venv\lib\site-packages\MySQLdb\connections.py", line 292, in query
    _mysql.connection.query(self, query)
django.db.utils.OperationalError: (1071, 'Specified key was too long; max key length is 1000 bytes')

I don't know what can I do, because I'm apprentice. I found answers, but it didn't help me.

Sorry for my bad English.

PS. When I start server it runs, but social-django doesn't work. Only that app can't migrate.

All the best, Dinson

回答1:

Disclaimer: I'm not an expert on this subject, I'm just stating my current practise, and suggestion here is just a suggestion ultimately you've decide if you going to use it.

Let's try and solve the problem, in your terminal go and type:

mysql -u root
then after you enter mysql monitor, you check if your fastandbeauty database still exists by typing SHOW_DATABASE;
if the database is still there drop it with DROP DATABASE fastandbeauty;
and then recreate and create a new fresh database by typing CREATE SCHEMA fastandbeauty DEFAULT CHARACTER SET utf8, if everything is all right monitor should omit a message Query OK, 1 row affected (0.00 sec), after that you can type SHOW_DATABASE again and see if the database exists
leave mysql monitor by typing \q
then you can do python manage.py migrate

that should create a new fastandbeauty database and you can continue working on it.

Now some future reference:

I suggest you don't use your development database on local production so you don't encounter things like this where you need to manually create/delete your db.

So you can dump your data into a file, with that file you will store some of your data for local development. How to use it?

Well you could make new git branch and name it something like local-dev-task-12, so you will work on this branch in the future, then you can create new database for this branch only and call the database fast_and_beauty12, just do the steps that I've all ready explained but before migration, cd into the folder where you keep your dump file and to this first:

mysql -u root -p fast_and_beauty_12 < DumpFastAndBeauty.sql - this will dump your data into new and fresh fast_and_beauty_12 created database
go into your setting db file and change the database name to that new one you've create so fastandbeauty >> fast_and_beauty12 so you can use it
and then you go and do python manage migrate.py

With this you will have a fresh database for that git branch and you can work on your db with out worrying of doing harm to the dev database.

NOTE:

You will not commit your new migration files from that branch, because that will make things go bad, you will git stash. them for future work.

After you've stashed migrations files go back to setting.py and change that name of you local database to you development database name so fast_and_beauty12 to fastandbeauty, migrate new changes into the development branch and you can do

python manage.py migrate, so that should populate you development database with new data.

The idea of this is to have new working database every time you create new branch for local development, it is a bit confusing in the beginning but after some time you will understand it, and start doing it more often. Potentially you don't need to do this if you are not going to work on your database, but still I think it's a good practice.