Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion for shorter code #1

Open
vdboor opened this issue May 31, 2012 · 2 comments
Open

Suggestion for shorter code #1

vdboor opened this issue May 31, 2012 · 2 comments

Comments

@vdboor
Copy link

vdboor commented May 31, 2012

Hi,

I came across your example, and it helped me understand app renamed a lot more. Thanks a lot :-)

I have a few suggestions for the project. Instead of sending a pull request, I can imagine you'd like to rebase / force push a new history instead. Hence, this ticket.

The second data migration for content-types can be merged into the first, by using:

    if not db.dry_run:
        ContentType.objects.filter(app_label='old_app').update(app_label='new_app')

(the only difference between a SchemaMigration and DataMigration is the fact that data migrations don't go through a dry-run)

The was_applied code can also be shortened:

def was_applied(migration_file_path, app_name):
    """true if migration with a given file name ``migration_file`` was applied to app with name ``app_name``"""
    migration_name = os.path.basename(migration_file_path).split('.')[0]
    return MigrationHistory.objects.exists(app_name=app_name, migration=migration_name)

I also found it useful to check for existing table names, not sure if it applies here. (code is if 'messages_message' in connection.introspection.table_names())

Hope this helps :-)

@evgenyfadeev
Copy link
Member

Awesome, glad it was useful.

Why is if not db.dry_run necessary?

Yeah, the shorter version of was_applied() is better. Not sure when I find the time to rebase this though:)...

@vdboor
Copy link
Author

vdboor commented May 31, 2012

Good to know, thanks :-)

About the dry_run: South distinguishes between a SchemaMigration and DataMigration, but the main difference is that a SchemaMigration is executed twice. The first time it's a "dry run", to see what the code would execute. The second time it does the actual execution. This feature is also used for commands like ./manage.py migrate --changes. Just grep through the South code, and you'll see that the difference is remarkably thin; the only difference is a property at one of the classes.

Hence, if you want to alter data in a SchemaMigration, or merge both together, it needs to check whether this is the first dry run, or second final run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants