Как сказано в названии, я не могу заставить миграцию работать.
Изначально приложение было под 1.6, поэтому я понимаю, что миграций там изначально не будет, и действительно, если я запускаю, python manage.py migrate
я получаю:
Operations to perform:
Synchronize unmigrated apps: myapp
Apply all migrations: admin, contenttypes, auth, sessions
Synchronizing apps without migrations:
Creating tables...
Installing custom SQL...
Installing indexes...
Running migrations:
No migrations to apply.
Если я myapp
внесу изменения в какие-либо модели , он все равно будет отображаться как не мигрированный, как и ожидалось.
Но если я бегу, python manage.py makemigrations myapp
то получаю:
No changes detected in app 'myapp'
Кажется, не имеет значения, что и как я запускаю команду, она никогда не определяет приложение как имеющее изменения и не добавляет в приложение никаких файлов миграции.
Есть ли способ принудить приложение к миграции и по существу сказать: «Это моя база для работы» или что-то в этом роде? Или я что-то упускаю?
Моя база данных - PostgreSQL, если это вообще помогает.
источник
Ответы:
Если вы переходите с существующего приложения, созданного в django 1.6, вам необходимо выполнить один предварительный шаг (как я выяснил), указанный в документации:
Документация не делает очевидным, что вам нужно добавить метку приложения к команде, поскольку первое, что она говорит вам сделать, это то,
python manage.py makemigrations
что не удастся. Первоначальная миграция выполняется при создании приложения в версии 1.7, но если бы вы перешли с версии 1.6, она бы не была выполнена. Дополнительные сведения см. В разделе «Добавление миграции в приложения» в документации.источник
python manage.py makemigrations APP_LABEL
для каждого?./manage.py startapp
, но мне все равно пришлось явно упомянуть ярлыкЭто может произойти по следующим причинам:
INSTALLED_APPS
список вsettings.py
(вы должны добавить либо имя приложения, либо путь с точками к подклассу AppConfig в apps.py в папке приложения, в зависимости от версии django, которую вы используете). См. Документацию: INSTALLED_APPSmigrations
папки внутри этих приложений. (Решение: просто создайте эту папку).__init__.py
файла вmigrations
папке с этими приложениями. (Решение: просто создайте пустой файл с именем __init__.py )__init__.py
файла в папке приложения. (Решение: просто создайте пустой файл с именем __init__.py )models.py
файла в приложенииmodels.py
не наследуетdjango.db.models.Model
models.py
Примечание. Распространенной ошибкой является добавление
migrations
папки в.gitignore
файл. При клонировании из удаленного репоmigrations
папка и / или__init__.py
файлы будут отсутствовать в локальном репо. Это вызывает проблему.Я предлагаю gitignore файлы миграции, добавив следующие строки в
.gitignore
файлисточник
__init__.py
папку вместе с миграциями.You don't have __init__.py file inside migrations folder of those apps. (Solution: Just create an empty file with name __init__.py)
.. и это было вызвано добавлением файлов в.gitignore
__init__.py
файл python 3.3 не потребуется внутри каталога, чтобы он обрабатывался как пакет python. см. этоХорошо, похоже, я пропустил очевидный шаг, но опубликую его на случай, если кто-то сделает то же самое.
При обновлении до 1.7 мои модели стали неуправляемыми (
managed = False
) - у меня они были как иTrue
раньше, но, похоже, все вернулось.Удаление этой строки (по умолчанию True) и последующий запуск
makemigrations
немедленно создали модуль миграции, и теперь он работает.makemigrations
не будет работать с неуправляемыми таблицами (что очевидно задним числом)источник
manage.py inspectdb
добавляет manage = False! в случае, если вы импортируете устаревшие базы данных, вы должны тщательно их настроить!app_label
такой жеМое решение здесь не описано, поэтому я его публикую. Я использовал его
syncdb
для проекта - просто чтобы запустить его. Затем, когда я попытался начать использовать миграции Django, он сначала подделал их, а затем сказал, что все в порядке, но с базой данных ничего не произошло.Мое решение заключалось в том, чтобы просто удалить все файлы миграции для моего приложения, а также записи базы данных для миграции приложений в
django_migrations
таблице.Затем я просто выполнил первоначальную миграцию:
./manage.py makemigrations my_app
с последующим:
./manage.py migrate my_app
Теперь я могу без проблем выполнять миграции.
источник
__init.py__
, это не сработает.Согласитесь с @furins. Если кажется, что все в порядке, но проблема все же возникает, проверьте, есть ли какой-либо метод свойства с тем же заголовком, что и атрибут, который вы пытаетесь добавить в класс модели.
источник
Это своего рода глупая ошибка, но наличие дополнительной запятой в конце строки объявления поля в классе модели делает строку неэффективной.
Это происходит при копировании и вставке файла def. из миграции, которая сама по себе определяется как массив.
Хотя, может быть, это кому-то поможет :-)
источник
Может быть, я опоздал, но вы пытались создать
migrations
в своем приложении папку с__init__.py
файлом?источник
Может это кому-то поможет. Я использовал вложенное приложение. project.appname и у меня на самом деле были project и project.appname в INSTALLED_APPS. Удаление проекта из INSTALLED_APPS позволило обнаружить изменения.
источник
Ответ находится в этой публикации stackoverflow от cdvv7788 Migrations in Django 1.7
У меня была точно такая же проблема, и все вышеперечисленное сработало отлично.
Я переместил свое приложение django в cloud9 и по какой-то причине так и не поймал первоначальную миграцию.
источник
Для меня сработало следующее:
У меня работали: Python 3.4, Django 1.10
источник
Люди вроде меня, которым не нравятся миграции, могут воспользоваться приведенными ниже инструкциями.
python manage.py makemigrations app_label
начальную миграцию.python manage.py migrate
Перед внесением изменений запустите создание таблиц.Если вы запутались в каком-либо из этих шагов, прочтите файлы миграции. Измените их, чтобы исправить схему или удалить ненужные файлы, но не забудьте изменить часть зависимостей следующего файла миграции;)
Надеюсь, это кому-то поможет в будущем.
источник
Вы хотите , чтобы проверить
settings.py
вINSTALLED_APPS
списке и убедитесь , что все приложения с моделями перечислены там.Запуск
makemigrations
в папке проекта означает, что он будет обновлять все таблицы, относящиеся ко всем приложениям, включенным вsettings.py
проект. После того, как вы его включите, оноmakemigrations
автоматически включится (это экономит много работы, поэтому вам не нужно запускатьmakemigrations app_name
каждое приложение в вашем проекте / сайте).источник
На всякий случай, если у вас есть конкретное поле, которое не идентифицируется makemigrations: дважды проверьте, есть ли у вас свойство с таким же именем.
пример:
field = django.db.models.CharField(max_length=10, default = '', blank=True, null=True) # ... later @property def field(self): pass
свойство "перезапишет" определение поля, поэтому изменения не будут идентифицированы
makemigrations
источник
hourly_rate = models.DecimalField
(отсутствует завершающий '()'), и он просто потерпел неудачу.Добавляю этот ответ, потому что мне помог только этот метод.
Я удалил
migrations
папку runmakemigrations
иmigrate
.Он по-прежнему сказал: « Никаких миграций применять».
Я зашел в
migrate
папку и открыл последний созданный файл,прокомментировал миграцию, которую хотел (он был обнаружен и введен там),
и запустил
migrate
снова.Это в основном ручное редактирование файла миграции.
Делайте это только в том случае, если вы понимаете содержание файла.
источник
Убедитесь, что ваша модель не такая
abstract
. Я действительно сделал ту ошибку, и это заняло некоторое время, поэтому я решил опубликовать ее.источник
Вы использовали
schemamigration my_app --initial
после переименования старую папку миграции? Попытайся. Может работать. Если нет - попробуйте воссоздать базу данных и выполнить миграцию syncdb +. У меня это сработало ...источник
schemamigration
существует - я думаю, это часть Юга? У меня сейчас вообще нет папки миграции. Удаление моегоmodels.py
и повторный запускinspectdb
, похоже, ничего не сделали.schemamigration
был с юга.makemigrations
это его замена.makemigrations --empty
Была та же проблема. Убедитесь, что какие бы классы вы ни определили в models.py, вы должны унаследовать класс models.Model.
class Product(models.Model): title = models.TextField() description = models.TextField() price = models.TextField()
источник
У меня была такая же проблема с двойным запуском makemigrations и всякого рода странным поведением. Оказалось, что корень проблемы в том, что я использовал функцию для установки дат по умолчанию в своих моделях, поэтому миграции обнаруживали изменение каждый раз, когда я запускал makemigrations. Ответ на этот вопрос направил меня на правильный путь: избегайте makemigrations для повторного создания поля даты
источник
Недавно я обновил Django с 1.6 до 1.8, и у меня было несколько приложений и миграций для них. Я использовал юг и
schemamigrations
для создания миграций в Django 1.6, который отсутствует в Django 1.8.Когда я добавил новые модели после обновления,
makemigrations
команда не обнаружила никаких изменений. А затем я попробовал решение, предложенное @drojf (1-й ответ), оно сработало нормально, но не удалось применить поддельную начальную миграцию (python manage.py --fake-initial
). Я делал это, так как мои таблицы (старые таблицы) уже были созданы.Наконец, это сработало для меня, удалил новые модели (или изменения модели) из models.py, а затем пришлось удалить (или переименовать для резервного копирования) папку миграции всех приложений и запустить python
manage.py
makemigrations для всех приложений, а затем это сделалpython manage.py migrate --fake-initial
. Это сработало как шарм. После того, как первоначальная миграция создана для всех приложений и поддельная первоначальная миграция, затем добавлены новые модели и выполнены регулярные процессыmakemigrations
миграции в этом приложении. Теперь изменения были обнаружены, и все прошло нормально.Я просто подумал поделиться этим здесь, если кто-то столкнется с той же проблемой (наличие
schemamigrations
юга для своих приложений), это может им помочь :)источник
Может, это кому-то поможет, у меня была такая же проблема.
Я уже создал две таблицы с классом сериализатора и представлениями. Поэтому, когда я хотел обновить, у меня была эта ошибка.
Я выполнил следующие шаги:
.\manage.py makemigrations app
.\manage.py migrate
models.py
1
и2
.models.py
5
.Если вы работаете с Pycharm, вам очень поможет местная история.
источник
Может это кому-то поможет.
Я удалил свой
models.py
и ожидалmakemigrations
созданияDeleteModel
операторов.Не забудьте удалить
*.pyc
файлы!источник
Миграции отслеживают изменения в БД, поэтому, если вы переходите с неуправляемого на управляемый, вам необходимо убедиться, что ваша таблица базы данных актуальна в соответствии с моделью, с которой вы имеете дело.
Если вы все еще находитесь в режиме разработки, я лично решил удалить файлы миграции в своей среде IDE, а также в таблице django_migrations, относящейся к моей модели, и повторно запустить указанную выше команду.
ПОМНИТЕ: если у вас есть миграция, которая заканчивается на _001 в вашей IDE и _003 в вашей базе данных. Django увидит, только если у вас есть миграция, заканчивающаяся на _004, для обновления чего-либо.
Две (миграции кода и базы данных) связаны и работают в тандеме.
Удачного кодирования.
источник
Возможно, вам придется подделать начальные миграции, используя команду ниже
источник
источник
В моем случае мне нужно было добавить свою модель в файл _ init _.py папки моделей, в которой была определена моя модель:
from myapp.models.mymodel import MyModel
источник
Добавил этот ответ, потому что ни один из вышеперечисленных вариантов не работал у меня.
В моем случае происходило что-то еще более странное ( версия Django 1.7 ). В моем models.py у меня была «лишняя» строка в конце моего файла (это была пустая строка), и когда я выполнил
python manage.py makemigrations
команду, результат был: «изменений не обнаружено».Чтобы исправить это, я удалил эту «пустую строку», которая была в конце моего файла models.py, и я снова запустил команду, все было исправлено и все изменения, внесенные в models.py, были обнаружены!
источник
Во-первых, это решение применимо к тем, кто сталкивается с той же проблемой во время развертывания на сервере heroku, я столкнулся с той же проблемой.
Для развертывания необходимо добавить django_heroku.settings (locals ()) в файл settings.py.
Изменения: когда я изменил указанную выше строку на django_heroku.settings (locals (), databases = False), она работала безупречно.
источник
Добавление моего 2c, поскольку ни одно из этих решений у меня не сработало, но это сработало ...
Я только что сбежал
manage.py squashmigrations
и удалил старые миграции (как файлы, так и строки в таблице базы данных django.migrations).В последнем файле миграции осталась такая строка:
replaces = [(b'my_app', '0006_auto_20170713_1735'), (b'my_app', '0007_auto_20170713_2003'), (b'my_app', '0008_auto_20170713_2004')]
Это явно сбило с толку Django и привело к странному поведению: запуск
manage.py makemigrations my_app
воссоздает первоначальную миграцию, как если бы ее не было. Удалениеreplaces...
строки устранило проблему!источник
python manage.py makemigrations accounts Миграции для 'accounts': accounts \ migrations \ 0001_initial.py - Создать модель клиента - Создать тег модели - Создать модель продукта - Создать модель Заказ
Примечание: здесь "accounts" - это имя моего приложения
источник