As you point out, there are good reasons to take other approaches. One advantage of pulp's restrictive approach is that it forces the migration writer to know with certainty which migrations will have already run. You can imagine the trouble that might ensue if two developers created migrations at the same time that did a transformation on the same field, and both merged cleanly. Whichever migration had the "losing" timestamp would be operating on data in a state that is different than what the writer expected.
Pulp 3.0 is expected to use django's migration framework, and the existing migration system will no longer be used. Michael On Tue, Oct 18, 2016 at 11:26 PM, Rohan McGovern <rmcgo...@redhat.com> wrote: > > 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 >
_______________________________________________ Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
