美文网首页Django中高级知识&应用
如何实现Django migration中DML操作的回滚(上)

如何实现Django migration中DML操作的回滚(上)

作者: Congroo_027c | 来源:发表于2019-04-24 22:47 被阅读0次

    这里也是因为最近接了一个Django migration优化的任务所以想到把调研的结果写一写以免以后忘了

    现象

    • Django默认支持单个DML操作的回滚,但不会将同一个文件中的多个DML操作视为一个事务
    • migration文件中经常使用migrations.RunPython命令进行metadata的增删改(极少情况下也会有migrations.RunSQL的调用)
    • 一个migration文件中经常会有多次的RunPython调用,一旦某部分执行失败,之前已经运行成功的RunPython调用不会被回滚,例如:
    def func_a(apps, schema_editor):
      do_db_cal()
      
    def func_b(apps, schema_editor):
      do_db_cal()
    
    class Migration(migrations.Migration):
      dependencies = [
        '...',
        '...'
      ]
      
      operations = [
        migrations.RunPython(func_a),
        migrations.RunPython(func_b),
      ]
    

    如果上述代码中的func_a调用成功,func_b调用报错,则func_a中的操作是不会回滚的,这样可能导致func_a的操作再次执行

    Django migration源码分析

    既然想要实现针对一整个migration文件的事务支持,首先第一步就是要来看看migration操作具体是如何实现的了


    我们都知道,Django中的migrate命令是python manage.py migrate,所以寻找migrate命令的源代码就是我们要做的第一步

    class Command(BaseCommand):
        ...
        
        def handle(self, *args, **options):
            ...
            if not plan:
                ...
            else:
                fake = options.get("fake")
                fake_initial = options.get("fake_initial")
                executor.migrate(targets, plan, fake=fake, fake_initial=fake_initial)
            ...
    

    这里列出了和migration操作直接相关的部分代码(migrate命令代码实在太多),当我们在执行python manage.py migrate命令时,如果参数正确,环境正确,实际上我们执行的就是executor.migrate命令来进行正常的migration操作,所以这里我们继续往下分析executor对象的migrate方法

    class MigrationExecutor(object):
        ...
    
        def migrate(self, targets, plan=None, fake=False, fake_initial=False):
            """
            Migrates the database up to the given targets.
    
            Django first needs to create all project states before a migration is
            (un)applied and in a second step run all the database operations.
            """
            if plan is None:
                plan = self.migration_plan(targets)
            # Create the forwards plan Django would follow on an empty database
            full_plan = self.migration_plan(self.loader.graph.leaf_nodes(), clean_start=True)
    
            all_forwards = all(not backwards for mig, backwards in plan)
            all_backwards = all(backwards for mig, backwards in plan)
    
            if not plan:
                pass  # Nothing to do for an empty plan
            elif all_forwards == all_backwards:
                # This should only happen if there's a mixed plan
                raise InvalidMigrationPlan(
                    "Migration plans with both forwards and backwards migrations "
                    "are not supported. Please split your migration process into "
                    "separate plans of only forwards OR backwards migrations.",
                    plan
                )
            elif all_forwards:
                self._migrate_all_forwards(plan, full_plan, fake=fake, fake_initial=fake_initial)
            else:
                # No need to check for `elif all_backwards` here, as that condition
                # would always evaluate to true.
                self._migrate_all_backwards(plan, full_plan, fake=fake)
    
            self.check_replacements()
    
        ...
    

    在上面的migrate方法中,根据注释的提示我们可以很轻松的找到我们在正常的migrate DDL或者DML操作中实际上执行的是self._migrate_all_forwards这个方法,继续往下看

    class MigrationExecutor(object):
        ...
    
            def _migrate_all_forwards(self, plan, full_plan, fake, fake_initial):
            """
            Take a list of 2-tuples of the form (migration instance, False) and
            apply them in the order they occur in the full_plan.
            """
            migrations_to_run = {m[0] for m in plan}
            state = ProjectState(real_apps=list(self.loader.unmigrated_apps))
            for migration, _ in full_plan:
                if not migrations_to_run:
                    # We remove every migration that we applied from this set so
                    # that we can bail out once the last migration has been applied
                    # and don't always run until the very end of the migration
                    # process.
                    break
                if migration in migrations_to_run:
                    if 'apps' not in state.__dict__:
                        if self.progress_callback:
                            self.progress_callback("render_start")
                        state.apps  # Render all -- performance critical
                        if self.progress_callback:
                            self.progress_callback("render_success")
                    state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
                    migrations_to_run.remove(migration)
                else:
                    migration.mutate_state(state, preserve=False)
    
            def apply_migration(self, state, migration, fake=False, fake_initial=False):
            """
            Runs a migration forwards.
            """
            if self.progress_callback:
                self.progress_callback("apply_start", migration, fake)
            if not fake:
                if fake_initial:
                    # Test to see if this is an already-applied initial migration
                    applied, state = self.detect_soft_applied(state, migration)
                    if applied:
                        fake = True
                if not fake:
                    # Alright, do it normally
                    with self.connection.schema_editor() as schema_editor:
                        state = migration.apply(state, schema_editor)
            # For replacement migrations, record individual statuses
            if migration.replaces:
                for app_label, name in migration.replaces:
                    self.recorder.record_applied(app_label, name)
            else:
                self.recorder.record_applied(migration.app_label, migration.name)
            # Report progress
            if self.progress_callback:
                self.progress_callback("apply_success", migration, fake)
            return state
    
        ...
    

    这里最后起作用的就是

    with self.connection.schema_editor() as schema_editor:
        state = migration.apply(state, schema_editor)
    

    这部分代码,其实到这里,稍微看过一点Django源码的同学应该能知道apply方法实际上就是每一个migration文件中的Migration类的一个方法了(没有分析经验的同学可能还得继续从这一步往上钻,不过这里就不再写更详细的分析过程了,实在太长...)

    分析结果

    所以最后我们要做的事就是分析apply方法,然后判断apply方法本身是否有办法或者支持实现事务,以及如何实现事务

    相关文章

      网友评论

        本文标题:如何实现Django migration中DML操作的回滚(上)

        本文链接:https://www.haomeiwen.com/subject/zccogqtx.html