You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :-)
The text was updated successfully, but these errors were encountered:
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.
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:
(the only difference between a
SchemaMigration
andDataMigration
is the fact that data migrations don't go through a dry-run)The
was_applied
code can also be shortened: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 :-)
The text was updated successfully, but these errors were encountered: