alembic revision - ошибка нескольких головок (из-за разветвления)
У меня есть приложение, и я хотел создать новую миграцию для него сегодня. Когда я бегу
$ alembic revision -m "__name__"
Я получил сообщение
Only a single head is supported. The script directory has multiple heads (due branching), which must be resolved by manually editing the revision files to form a linear sequence.
Run `alembic branches` to see the divergence(s).
Бег
alembic branches
ничего не дает
Я новичок в Alembic. Над этим приложением работают 2 разработчика, и у нас есть 2 ветки git - master & development (я не уверен, что это как-то связано с этим).
Любая подсказка о чем это?
4 ответа
Я бегал
$ python manage.py db history
И в результате я получил
vagrant@precise64:/vagrant$ python manage.py db history
Rev: 29c319804087 (head)
Parent: 313837798149
Path: migrations/versions/29c319804087_.py
empty message
Revision ID: 29c319804087
Revises: 313837798149
Create Date: 2014-03-05 21:26:32.538027
Rev: 313837798149
Parent: 280061454d2a
Path: migrations/versions/313837798149_.py
empty message
Revision ID: 313837798149
Revises: 280061454d2a
Create Date: 2014-01-10 03:19:39.838932
Rev: 280061454d2a
Parent: None
Path: migrations/versions/280061454d2a_.py
empty message
Revision ID: 280061454d2a
Revises: None
Create Date: 2013-12-08 03:04:55.885033
Rev: 2e74f61d3b80 (head)
Parent: 49501407aec9
Path: migrations/versions/2e74f61d3b80_o2_lease.py
o2 lease
Revision ID: 2e74f61d3b80
Revises: 49501407aec9
Create Date: 2014-02-28 10:38:06.187420
Rev: 49501407aec9
Parent: None
Path: migrations/versions/49501407aec9_.py
empty message
Revision ID: 49501407aec9
Revises: None
Create Date: 2014-01-22 11:27:08.002187
То, что вы можете увидеть здесь, это 2 разные ветви. Один начинается с 49501407aec9, а второй с 280061454d2a. Я переместил 49501407aec9 и следующий 2e74f61d3b80 из каталога /version, запустил
$ python manage.py db revision
и он создал новый файл миграции.
Пожалуй, самое обычное (и надежное) решение заключается в использовании alembic merge heads
, Таким же образом, когда у вас есть две ветви в Git, вы можете объединить их вместе с коммитом слияния, в Alembic, когда у вас есть две ветви, вы можете вернуть их вместе с ревизией слияния.
Например, предположим, что у нас есть ревизия 1a6b1a4a0574, которая добавляет таблицу A, и ревизия 2e49118db057, которая добавляет таблицу B. Мы можем видеть эти ревизии (обе помечены как (head)
) в alembic history
:
$ alembic history
<base> -> 2e49118db057 (head), Add table B
<base> -> 1a6b1a4a0574 (head), Add table A
Тогда мы можем объединить их, запустив alembic merge heads
:
$ alembic merge heads
Generating /Users/markamery/alembictest/alembic/versions/409782f4c459_.py ... done
$ alembic history
2e49118db057, 1a6b1a4a0574 -> 409782f4c459 (head) (mergepoint), empty message
<base> -> 2e49118db057, Add table B
<base> -> 1a6b1a4a0574, Add table A
Если одна из ваших ревизий уже была где-то запущена (в том числе на компьютере разработчика одного из ваших коллег), то вы, вероятно, хотите использовать alembic merge
вместо того, чтобы возиться с down_revision
одной из ревизий, как предлагают другие ответы здесь. Опасность возиться с понижающей версией состоит в том, что она может привести к тому, что пересмотр не будет применен. Например, предположим, что ваш коллега Боб уже снял ветку с ревизией 2e49118db057 и запустил alembic upgrade head
, создав таблицу B. Затем вы решаете изменить down_revision
2e49118db057, чтобы указать на 1a6b1a4a0574, который Боб никогда раньше не видел и не запускал. Боб срывает твою сдачу, бежит alembic upgrade head
и... ничего не происходит, потому что, что касается Алембика, он уже на head
и не нужно запускать 1a6b1a4a0574. И поэтому Боб никогда не получает таблицу A и, вероятно, никогда не узнает, почему его база данных находится в неисправном состоянии.
Не ломайте базу данных Боба - вместо этого сделайте ревизию слияния.
Эта проблема возникает, когда две алембические миграции происходят от одной и той же миграции. Обычно это происходит, когда несколько человек вносят изменения в схему. Чтобы это исправить, вам просто нужно отрегулироватьdown_revision
вашей миграции, чтобы быть последней. Бег alembic history
показывает нам это:
2f4682466279 -> f34e92e9dc54 (head), Fifth revision (on a separate branch)
2f4682466279 -> f673ac37b34a (head), Fifth revision (local)
2dc9337c3987 -> 2f4682466279, Fourth revision
0fa2aed0866a -> 2dc9337c3987, Third revision
22af4a75cf06 -> 0fa2aed0866a, Second revision
9a8942e953eb -> 22af4a75cf06, First revision
Вы можете видеть, что одна из Пятых ревизий была сделана локально, и это нижестоящая ревизия2f4682466279
но тот, кто сделал другую Пятую ревизию, тоже получил такую же нижестоящую ревизию.
Зайдите в один из файлов пятой ревизии и обновите down_revision
переменная для ссылки на другую пятую ревизию, например так:
f673ac37b34a -> f34e92e9dc54 (head), Fifth revision (on a separate branch)
2f4682466279 -> f673ac37b34a, Fifth revision (local)
2dc9337c3987 -> 2f4682466279, Fourth revision
0fa2aed0866a -> 2dc9337c3987, Third revision
22af4a75cf06 -> 0fa2aed0866a, Second revision
9a8942e953eb -> 22af4a75cf06, First revision
В этом случае я обновил миграцию f34e92e9dc54
иметь down_revision='f673ac37b34a'
,
Использовать
merge
команда.
Слияние Alembic — это файл миграции, который объединяет два или более «головных» файла вместе. Если две ветки, которые у нас есть прямо сейчас, можно назвать «древовидной» структурой, введение этого файла слияния превратит ее в «алмазную» структуру:
-- ae1027a6acf -->
/ \
<base> --> 1975ea83b712 --> --> mergepoint
\ /
-- 27c6a30d7c24 -->
Следовательно;
$ alembic merge -m "merge ae1 and 27c" ae1027 27c6a
Generating /path/to/foo/versions/53fffde5ad5_merge_ae1_and_27c.py ... done
Если вы предпочитаете использовать
command
:
>>> from alembic.config import Config
>>> from alembic import command
>>> alembic_cfg = Config("path to alembic.ini")
>>> command.merge(alembic_cfg, revisions=["27c6a30d7c24", "ae1027a6acf"], message="Merge 27c6a30d7c24 and ae1027a6acf")
Ссылка