Подтвердить что ты не робот

Django 1.8 migrate не создает таблицы

yekabathula-macbookair2:roster yekabathula$ python manage.py migrate
Operations to perform:
  Synchronize unmigrated apps: staticfiles, messages
  Apply all migrations: admin, contenttypes, api, auth, sessions
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
  Installing custom SQL...
Running migrations:
  Rendering model states... DONE
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying api.0001_initial... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying sessions.0001_initial... OK
yekabathula-macbookair2:roster yekabathula$ python manage.py syncdb
/Library/Python/2.7/site-packages/django/core/management/commands/syncdb.py:24: RemovedInDjango19Warning: The syncdb command will be removed in Django 1.9
  warnings.warn("The syncdb command will be removed in Django 1.9", RemovedInDjango19Warning)

Operations to perform:
  Synchronize unmigrated apps: staticfiles, messages
  Apply all migrations: admin, contenttypes, api, auth, sessions
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
  Installing custom SQL...
Running migrations:
  No migrations to apply.

После выполнения миграции python manage.py таблицы не создаются в базе данных с моих моделей .py, он может создавать другие таблицы из django_session и т.д. Есть ли что-нибудь еще, что мне нужно для этого?

4b9b3361

Ответ 1

Я столкнулся с аналогичной проблемой в Django 1.10, и ни один из вышеперечисленных решений не работал у меня.

В итоге работала эта команда:

python manage.py migrate --fake myappname zero

Это reset все миграции (в нулевое состояние)

Далее следуют:

python manage.py migrate myappname

создал таблицы для меня.

Если вы не хотите откатываться в исходное (ноль) состояние, но скажите на номер миграции 0005 (последний перенос, который работал), вы можете сделать это:

python manage.py migrate --fake myappname 0005

Затем перейдите к действительной миграции:

python manage.py migrate myappname

Подробнее в docs

Ответ 2

В моем случае файл __init__.py отсутствовал в папке APP/migrations/. Если у вас его нет, все, что ему нужно, это пустой файл __init__.py.

Ответ 3

я столкнулся с той же проблемой. После долгих раскопок я нашел решение. Я использую Django 1.11,

Если вы хотите начать все сначала,

1)delete all the files in your migrations folder except __init__.py
2)drop database
3)create database
4)python makemigrations
5)python migrate

если у вас есть reset_db, вместо 2-го и 3-го шагов вы можете использовать reset_db.

python manage.py reset_db

Ответ 4

У меня была аналогичная проблема, и я просто вычислил ее. У меня есть несколько баз данных. Мой локальный (тот, который не обновляется) - это база данных MySQL. Другие - MS SQL Server и MySQL. У меня есть маршрутизаторы для других баз данных, так как я их не управляю, и (в Django 1.6) использовал маршрутизаторы для указания allow_sync() = False. С 1.7 я изменил это, чтобы allow_migrate() = False. НО Я НЕ ДОБАВЛЯЛ МАРШРУТ ДЛЯ МОЙ ЛОКАЛЬНОЙ БАЗА ДАННЫХ. По умолчанию используется allow_migrate() = False, если его нет. В результате миграция просто провалилась молча (ссылка: https://docs.djangoproject.com/en/1.7/topics/db/multi-db/). Я добавил маршрутизатор для своей локальной базы данных, установив allow_migrate(), чтобы вернуть True, и теперь мои миграции фактически создают мои таблицы.

Ответ 5

  • Удалить существующие таблицы моделей.

  • Удалить папку переноса в папке приложения.

  • Удалить все связанные записи миграции в таблице
    "django_migrations".

  • Теперь вы получаете четкую модель и базу данных. Использовать makemigrations и мигрировать для создания таблицы.

Надеюсь помочь вам.

Ответ 6

Это решило проблему для меня (кстати, я использую Workbench MySQL):

  • Запустите этот sql: SET FOREIGN_KEY_CHECKS = 0;
  • Выберите все таблицы в базе данных django (щелкните по первой таблице, затем нажмите и удерживайте shift, затем нажмите на последнюю таблицу). Затем щелкните правой кнопкой мыши и выберите "Drop n tables" (где n - количество выбранных таблиц)
  • затем запустите python manage.py migrate
  • Наконец, восстановите параметры проверки внешнего ключа, запустив этот sql: SET FOREIGN_KEY_CHECKS = 1;

Примечание. Прежде чем принять эту решительную меру, я пробовал, что

Ответ 7

Проблема: Когда вы применяете миграции в Джанго впервые, Джанго создает таблицу этой модели в базе данных и знаках где - то в своем собственном файле (класс):

'initial = True' 
  • Когда вы затем пытаетесь изменить схему этой таблицы, она сначала проверяет, если initial = True

  • если начальный атрибут класса не найден, миграция будет считаться "начальной"

  • В случае, если initial = True мы должны использовать

    python manage.py migrate --fake-initial
    

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

Поддельная первоначальная миграция использует методы CreateModel() и AddField().


Решение:

>> python manage.py makemigrations <AppName>
>> python manage.py migrate --fake-initial

Ответ 8

Я использую MySQL и попал в эту проблему после удаления 0001_initial.py миграции 0001_initial.py и всех пользовательских таблиц, 0001_initial.py из БД, чтобы попытаться восстановить все они...

Решил эту проблему, просто удалив эти строки в таблице django_migrations...

enter image description here

После этого команда $ python manage.py migrate заново $ python manage.py migrate все мои пользовательские таблицы.

Ответ 9

Изменить управляемый = True (если он установлен в False) в models.py

class Meta:
    managed = False
    db_table = 'table_name'

к

class Meta:
    managed = True
    db_table = 'table_name'

Ответ 10

  1. Если вы хотите сделать это только для вашего приложения, а не для всех приложений, то очистите записи миграции вашего приложения из таблицы 'django_migrations' в вашей БД.
  2. Python manage.py makemigrtions
  3. питон

Ответ 11

  1. Удалить базу данных
  2. удалить папку migration
  3. запустить команду migrate
  4. запустить команду makemigrations
  5. запустить команду migrate

Это создаст все таблицы отлично

Ответ 12

Чтобы избежать удаления критически важных баз данных, вы также можете рассмотреть properties молчания ниже Class Meta: например, эта модель:

class Blog(models.Model):
    category = models.CharField(max_length=100)
    title = models.CharField(max_length=100)
    date_added = models.DateTimeField()
    merits = models.CharField(max_length=300, blank=True)
    demerits = models.CharField(max_length=300, blank=True)
    class Meta:
        managed = True
        db_table = 'weblog'
        verbose_name_plural = "Blog"

    @property
    def content_min(self):
        return truncatechars(self.content, 50)

Затем вы можете запустить makemigrations и выполнить migrate и ваша таблица будет создана.