We're working on some custom Pulp migrations to fix up some data issues
in our Pulp installation.

The migration mechanism has an annoying restriction: there aren't
allowed to be any gaps in the migration sequence.  For example, if I
have 0001_my_first_migration.py and 0003_add_email_addresses_to_users.py
then pulp-manage-db won't run migration 3 due to the absence of a
migration numbered 2.

There is a good reason for it not to work this way: this means that the
next number in the sequence is in contention between all separately
developed patches which might need to add migrations.  For example, if
there are currently migrations 1-3, multiple developers working on new
migrations concurrently are all forced to use number 4 (otherwise their
code won't run) but in the end, only one of them can "win" and all the
others will have to renumber theirs later.  If the migrations are
independent from each other, that's wasted time.

Compare with e.g. ActiveRecord where migrations are "numbered" by
timestamp at time of generation, and there's no problem merging branches
where unrelated migrations were authored separately.

Is there a particular reason for the current pulp migration system to
work this way?

Pulp-list mailing list

Reply via email to