Modify

Ticket #411 (closed enhancement: fixed)

Opened 4 years ago

Last modified 2 years ago

Option to Ignore Ghost Migrations

Reported by: Andy McCurdy Owned by: andrew
Priority: major Milestone: 0.7.1
Component: commands Version: 0.7
Keywords: Cc:

Description

It would be convenient to add an option to the migrate command that instructs the migration to ignore warnings about ghost migrations. This problem generally stems from developing on multiple branches against the same database instance. A simple use case:

I develop my new feature in a separate branch. I've added some migrations and run them against my DB instance. A bug report comes in that I need to fix in trunk immediately. The bug fix requires a database migration. When I try to run my bug-fix migration in trunk, South complains that it can't find my feature migrations. I know they're missing, but I really want to run my bug-fix migration to test it and close to bug.

My current work around is to fake-add the missing migrations at their correct location on disk so South doesn't complain. This works, but it's far more effort than an --ignore-ghost-migrations options would be.

Happy to submit a patch if you're OK with the option being added.

Attachments

Change History

comment:1 Changed 4 years ago by amccurdy

  • Reporter changed from anonymous to Andy McCurdy

comment:2 Changed 4 years ago by andrew

  • Status changed from new to assigned
  • Milestone set to 0.7.1

Definitely +1 on this idea; am more than happy to take a patch for it.

comment:3 Changed 4 years ago by amccurdy

Sent you a pull request on bitbucket with the change.

comment:4 Changed 4 years ago by andrew

  • Status changed from assigned to closed
  • Resolution set to fixed

Thanks, pulled and merged as [965340231707].

comment:5 Changed 4 years ago by anonymous

Thank you for adding this feature! I needed it today...

comment:6 Changed 4 years ago by Eddie Bishop <eddie.bishop@…>

  • Status changed from closed to reopened
  • Resolution fixed deleted

I'm getting the "south.exceptions.GhostMigrations?" exception when using the "convert_to_south" command with a new app that is unrelated to the ghost migration that the exception is about. The initial migration for the app that I'm trying to migrate was created, but not applied, because of the GhostMigrations? error. I assume that if ghost migrations weren't an issue, the migration would be fake-applied as well because the "convert_to_south" command is supposedly supposed to "pretend to apply it", according to the docs.

In addition, the convert_to_south command doesn't accept --ignore-ghost-migrations as an option. If one tries to specify it as an option, the command does nothing at all except output a usage message and warning:

Usage: ./manage.py convert_to_south [options]

Quickly converts the named application to use South if it is currently using syncdb.

./manage.py: error: no such option: --ignore-ghost-migrations

Tested on django 1.2.1, south 0.7.1

comment:7 Changed 4 years ago by Eddie Bishop <eddie.bishop@…>

full output of when I tried to migrate an app to south when there was a ghost migration present:

./manage.py convert_to_south orchard
Creating migrations directory at '/home/ebishop/m1-www-beyond/beyond/applications/partner/orchard/migrations'...
Creating __init__.py in '/home/ebishop/m1-www-beyond/beyond/applications/partner/orchard/migrations'...
 + Added model orchard.Genre
 + Added model orchard.SubGenre
 + Added model orchard.Mood
 + Added model orchard.Instrument
 + Added model orchard.Theme
 + Added model orchard.Language
 + Added model orchard.ProductMetadata
 + Added M2M table for sub_genres on orchard.ProductMetadata
 + Added M2M table for moods on orchard.ProductMetadata
 + Added M2M table for instruments on orchard.ProductMetadata
 + Added M2M table for themes on orchard.ProductMetadata
 + Added model orchard.SourceFileHistory
 + Added model orchard.ReleaseDate
 + Added unique constraint for ['product', 'country'] on orchard.ReleaseDate
 + Added model orchard.SaleStartDate
 + Added unique constraint for ['product', 'country'] on orchard.SaleStartDate
 + Added model orchard.ReleaseArtist
 + Added unique constraint for ['product', 'name'] on orchard.ReleaseArtist
 + Added model orchard.ProductArtist
 + Added M2M table for similar_artists on orchard.ProductArtist
 + Added M2M table for influencers on orchard.ProductArtist
 + Added M2M table for contemporaries on orchard.ProductArtist
 + Added M2M table for followers on orchard.ProductArtist
 + Added model orchard.SimilarArtist
 + Added model orchard.ArtistInfluencer
 + Added model orchard.ArtistContemporary
 + Added model orchard.ArtistFollower
 + Added model orchard.Volume
 + Added unique constraint for ['product', 'sequence'] on orchard.Volume
 + Added model orchard.RightsGranted
 + Added model orchard.Track
 + Added unique constraint for ['product', 'volume', 'sequence'] on orchard.Track
 + Added model orchard.ParticipantRole
 + Added model orchard.Participant
 + Added model orchard.TrackRestrictedTo
 + Added unique constraint for ['track', 'country'] on orchard.TrackRestrictedTo
 + Added model orchard.TrackRestrictedFrom
 + Added unique constraint for ['track', 'country'] on orchard.TrackRestrictedFrom
Created 0001_initial.py. You can now apply this migration with: ./manage.py migrate orchard
Traceback (most recent call last):
  File "./manage.py", line 20, in <module>
    execute_manager(settings)
  File "/usr/lib/pymodules/python2.6/django/core/management/__init__.py", line 438, in execute_manager
    utility.execute()
  File "/usr/lib/pymodules/python2.6/django/core/management/__init__.py", line 379, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/lib/pymodules/python2.6/django/core/management/base.py", line 191, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/lib/pymodules/python2.6/django/core/management/base.py", line 218, in execute
    output = self.handle(*args, **options)
  File "/home/ebishop/m1-www-beyond/beyond/contrib-applications/south/management/commands/convert_to_south.py", line 74, in handle
    management.call_command("migrate", app, "0001", fake=True, verbosity=verbosity)
  File "/usr/lib/pymodules/python2.6/django/core/management/__init__.py", line 166, in call_command
    return klass.execute(*args, **defaults)
  File "/usr/lib/pymodules/python2.6/django/core/management/base.py", line 218, in execute
    output = self.handle(*args, **options)
  File "/home/ebishop/m1-www-beyond/beyond/contrib-applications/south/management/commands/migrate.py", line 109, in handle
    ignore_ghosts = ignore_ghosts,
  File "/home/ebishop/m1-www-beyond/beyond/contrib-applications/south/migration/__init__.py", line 182, in migrate_app
    applied = check_migration_histories(applied, delete_ghosts, ignore_ghosts)
  File "/home/ebishop/m1-www-beyond/beyond/contrib-applications/south/migration/__init__.py", line 99, in check_migration_histories
    raise exceptions.GhostMigrations(ghosts)
south.exceptions.GhostMigrations:

 ! These migrations are in the database but not on disk:
    <warner: 0002_changes_to_sourcefile>
 ! I'm not trusting myself; either fix this yourself by fiddling
 ! with the south_migrationhistory table, or pass --delete-ghost-migrations
 ! to South to have it delete ALL of these records (this may not be good).

comment:8 Changed 4 years ago by Eddie Bishop <eddie.bishop@…>

I just noticed a discrepancy. The output from that command says
"Created 0001_initial.py. You can now apply this migration with: ./manage.py migrate orchard"
which is contrary to the docs at http://south.aeracode.org/docs/convertinganapp.html which say the new migration will be pretend-applied. This is a minor issue however.

comment:9 Changed 4 years ago by andrew

  • Status changed from reopened to closed
  • Resolution set to fixed

Firstly, the text is wrong, because convert_to_south just runs the two underlying commands - the output should probably be suppressed.

Secondly, the ignore ghost migrations option is only in South development trunk; it's not made it into a release yet. I should probably do a release soon, but the main development trunk is stable (and in a release-ready state) so you can just use that if you want.

comment:10 Changed 4 years ago by andrew

Oh, wait, ignore that, it IS in 0.7.1. Sorry, I'm rather tired.

The error seems to be that you passed --ignore-ghost-migrations not --delete-ghost-migrations.

comment:11 Changed 4 years ago by Eddie Bishop <eddie.bishop@…>

But I don't want to delete ghost migrations. :) I'm saying that "--ignore-ghost-migrations" works fine for "manage" command, but not for "convert_to_south" command.

comment:12 Changed 4 years ago by Eddie Bishop <eddie.bishop@…>

Since it just runs the two commands, it should be able to take the options that the two commands accept. The migrate command does except "--ignore-ghost-migrations" as an option when used on its own, but "convert_to_south" command doesn't accept the "--ignore-ghost-migrations", therefore it is impossible to pass it as an option to "migrate" when it is wrapped inside of "convert_to_south".

I suppose this is a feature enhancement then? I propose that the "convert_to_south" command be modified to allow '--ignore-ghost-migrations' as an option, and if supplied, it merely passes it to the underlying "migrate" command.

comment:13 Changed 4 years ago by andrew

Oh, right, sorry - this is one of the problems with reopening tickets, the subject is often not the same. Since this is really a different bug, could you open a new ticket?

comment:14 Changed 4 years ago by Eddie Bishop <eddie.bishop@…>

See #519

View

Add a comment

Modify Ticket

Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.