We're working on some custom Pulp migrations to fix up some data issues in our Pulp installation. https://docs.pulpproject.org/dev-guide/newtypesupport/plugin/migrations.html
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. http://guides.rubyonrails.org/active_record_migrations.html Is there a particular reason for the current pulp migration system to work this way? _______________________________________________ Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list