2016-02-08 2 views
3

Если кто-то использует Django, что происходит с изменениями, внесенными непосредственно в базу данных (в моем случае postgres) через pgadmin или psql?Редактировать базу данных за пределами Django ORM

Как такие изменения обрабатываются миграциями? Имеют ли они преимущество над тем, что думает ORM о состоянии дел, или Django переопределяет их и навязывает собственное чувство истории изменений?

В конце концов, как любые из этих проблем были устранены или исключены git, если вообще?

Спасибо.

+0

Вы имеете в виду изменение схемы или данных? – Sayse

+0

, но, может быть, я должен был спросить обо всех обоих? –

ответ

1

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

class SomeModel(models.Model): 

    class Meta: 
     managed = False 
     db_table = "some_table_name" 

    name = models.Fields.... 

Обратите внимание, что вы можете У меня есть оба пути, поэтому миграция предпочтительнее, когда это возможно. Вы всегда можете определить пользовательскую миграцию SQL, которая сохранит необходимость в внешних изменениях. Однако иногда вам нужно обрабатывать схему в другом месте вместо миграции, а затем использовать managed = False

1

Система миграции не рассматривает вашу текущую схему вообще. Он создает свою картину из графика предыдущих миграций и текущего состояния models.py. Это означает, что если вы внесете изменения в схему извне этой системы, она будет не синхронизирована; если вы затем сделаете эквивалентное изменение в models.py и создаете миграцию, при запуске вы, вероятно, получите сообщение об ошибке.

По этой причине вам следует избегать этого. Если это уже сделано, вы можете применить конфликтующий переход в поддельном режиме, который просто отмечает его как выполненный без фактического запуска кода с базой данных. Но проще всего сделать все с помощью миграций в первую очередь.

git не оказывает никакого влияния на это вообще, кроме как повторять, что миграции являются кодом и должны быть добавлены в ваше git-репо.

+0

На самом деле оба ответа были полезны, но я выбрал Aviah, потому что поддельная миграция не решает проблему, если тот, который вы хотите избавиться, это тот, который из psql/pgadmin. –

Смежные вопросы