Re: [Pulp-list] Pulp migration order

[Michael Hrivnak]

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 
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

[Pulp-list] Pulp migration order

[Rohan McGovern]

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