миграция в django на устаревшую базу данных дает ошибку

Справочная информация: я новичок в django, лучше вооружён python, а также совсем новичок в mysql (и, следовательно, в mariaDB). Я работаю в среде Windows 7 со следующими версиями:

  • Джанго 1.9.1
  • МарияДБ 10.0.20
  • Питон 3.4.4
  • mysql-connector\Python 2.1.3 для Python 3.4

Цель: я пытаюсь создать базу данных mariaDB и веб-интерфейс для нее с помощью django. Я заранее создал базу данных в mysql и теперь пытаюсь создать проект django, используя эту базу данных в качестве устаревшей базы данных.

Проблема: я получил модели в свой проект django следующим образом:

python manage.py inspectdb > models.py

и это работало нормально. Проверил также models.py, и они выглядели так, как должны.

Теперь, если я попытаюсь перейти для создания таблиц на основе django в мою устаревшую базу данных следующим образом:

python manage.py migrate

Я продолжаю получать множество вложенных ошибок, последняя из которых:

django.db.migrations.exceptions.MigrationsSchemaMissing: Unable to create the django_migrations table (Table 'mydb'.'django_migrations' already exists. Please DISCARD the tablespace before IMPORT.)

Я понял, что таблица осталась в моей папке базы данных с предыдущей попытки, но ее удаление не помогает. Даже если я проверю из командной строки базы данных, что единственные оставшиеся таблицы являются родными для моей базы данных, это же сообщение об ошибке все еще появляется. В какой-то момент я задался вопросом, есть ли какая-то проблема с соединителем, который я использую, поскольку он не рекомендуется (mysqlclient).

Где-то я обнаружил, что миграция даже не потребуется. Это, очевидно, спасло бы меня, но я понятия не имею, могу ли я пойти на это решение. В идеале база данных будет управляться позже в режиме онлайн, и пользователи с учетными записями администратора смогут добавлять туда записи. Однако в противном случае база данных должна просто возвращать данные.

EDIT: исправлено сообщение об ошибке в строке python manage.py inspectdb > models.py.

ИЗМЕНИТЬ 29.1. Выполнение миграции как:

python manage.py migrate --fake

приводит к той же ошибке.

Проблема сохраняется даже после удаления проекта django и запуска его заново.

EDIT v2 29.1. В папке базы данных есть только один из необходимых файлов таблиц для таблицы django_migrations. Должен быть django_migrations.ibd И django_migrations.frm. Однако после запуска миграции остается только один файл: django_migrations.ibd.

Здесь происходило что-то подобное, но с другим файлом проблемы mysqldump с ошибкой восстановления: 'ПОжалуйста, ОТМЕНИТЕ табличное пространство перед ИМПОРТОМ'. Это хорошо объяснено в выбранном ответе.

Я думаю, что это связано с моей проблемой, но не могу понять, что может помочь и что с этим делать.

EDIT v3 29.1. И, наконец, я заметил файл с ошибкой django. Это регистратор миграции django в C:\Python34\lib\site-packages\django\db\migrations\recorder.py в строке 59.

def ensure_schema(self):
    """
    Ensures the table exists and has the correct schema.
    """
    # If the table's there, that's fine - we've never changed its schema
    # in the codebase.
    if self.Migration._meta.db_table in self.connection.introspection.table_names(self.connection.cursor()):
        return
    # Make the table
    try:
        with self.connection.schema_editor() as editor:
            editor.create_model(self.Migration)
    except DatabaseError as exc:
        raise MigrationSchemaMissing("Unable to create the django_migrations table (%s)" % exc)

Где последней строкой, вызывающей ошибку, является строка 59. Как ни странно, функция должна работать, если таблица существует. Единственное, что я могу придумать (как и в моем предыдущем редактировании), это то, что действительно по какой-то причине файл frm не создается в процессе миграции.

Почему так происходит, я не понимаю.


person scinaya    schedule 27.01.2016    source источник
comment
Я решил попробовать течь без миграций. Обновление строк и доступ к данным в базе данных работают нормально, поэтому этого должно быть достаточно для моего проекта. Однако, если кто-нибудь выяснит, почему эта ошибка продолжает происходить, мне было бы интересно узнать.   -  person scinaya    schedule 02.02.2016