PythonWeb
  • Introduction
  • Python Web 开发: 测试驱动方法
    • 准备工作和应具备的知识
    • 前言
    • 第一部分 TDD 和 Django 基础
      • 第 1 章 使用功能测试协助安装 Django
      • 第 2 章 使用 unittest 模块扩展功能测试
      • 第 3 章 使用单元测试测试简单的首页
      • 第 4 章 编写这些测试有什么用
      • 第 5 章 保存用户输入
      • 第 6 章 完成最简可用的网站
    • 第二部分 Web 开发要素
      • 第 7 章 美化网站: 布局, 样式, 及其测试方法
      • 第 8 章 使用过渡网站测试部署
      • 第 9 章 使用 Fabric 自动部署
      • 第 10 章 输入验证和测试的组织方式
      • 第 11 章 简单的表单
      • 第 12 章 高级表单
      • 第 13 章 试探 JavaScript
      • 第 14 章 部署新代码
    • 第三部分 高级话题
      • 第 15 章 用户认证_集成第三方插件以及 JavaScript 模拟技术的使用
      • 第 16 章 服务器端认证,在 Python 中使用模拟技术
      • 第 17 章 测试固件,日志和服务器端调试
      • 第 18 章 完成My Lists页面:由外而内的TDD
      • 第 19 章 测试隔离和倾听测试的心声
      • 第 20 章 持续集成
      • 第 21 章 简单的社会化功能,页面模式,以及练习
      • 第 22 章 测试运行速度的快慢和炽热的岩浆
    • 附录
      • 附录 A PythonAnywhere
      • 附录 B 基于类的 Django 视图
      • 附录 C 使用 Ansible 配置服务器
      • 附录 D 测试数据库迁移
Powered by GitBook
On this page
  • D.1 尝试部署到过渡服务器
  • D.2 在本地执行一个用于测试的迁移
  • D.2.1 输入有问题的数据
  • D.2.2 从线上网站中复制测试数据
  • D.2.3 确认的确有问题
  • D.3 插入一个数据迁移
  • 重新创建以前的迁移
  • D.4 一起测试这两个迁移
  • D.5 小结

Was this helpful?

  1. Python Web 开发: 测试驱动方法
  2. 附录

附录 D 测试数据库迁移

Django-migrations 及前身 South 已经出现好多年了,所以一般没必要测试数据库迁移。但有时我们会使用一种危险的迁移,即引入新的数据完整性越苏。

在大型项目中,如果有敏感数据,在生产数据中执行迁移之前,你可能想先在一个安全的环境中测试,增加一些自信。

测试迁移的另一个常见原因是测速——执行迁移时经常要把网站下线,而且如果数据集比较大,用时并不短。所以最好提前知道迁移要执行多长时间。

D.1 尝试部署到过渡服务器

数据库中某些现有的数据违反了完整性越苏条件,所以当尝试应用约束条件时,数据库表达了不满。

为了处理这种问题,需要执行“数据迁移”。首先,要在本地搭建一个测试环境。

D.2 在本地执行一个用于测试的迁移

使用线上数据库的副本测试迁移。

测试时使用真实数据一定要小心。例如,数据中可能有客户的真实电子邮件地址。

D.2.1 输入有问题的数据

在线上网站中新建一个清单,输入一些重复的待办事项

D.2.2 从线上网站中复制测试数据

从线上网站中复制数据库:

scp watch@watch0.top /home/watch/sites/watch0.top/database/db.sqlite3 .
mv ../database/db.sqlite3 ../database/db.sqlite3.bak
mv db.sqlite3 ../database/db.sqlite3

D.2.3 确认的确有问题

现在,本地还有一个未执行迁移的数据库,而且数据库中有一些问题数据。如果尝试执行 migrate 命令,会看到错误。

D.3 插入一个数据迁移

git rm lists/migrations/0005_list_item_unique_together.py
python3 manage.py makemigrations lists --empty
mv lists/migrations/0005_ lists/migrations/0005_remove_duplicates.py*
# lists/migrations/0005_remove_duplicates.py
# encoding: utf8
from django.db import models, migrations

def find_dupes(apps, schema_editor):
    List = apps.get_model("lists", "List")
    for list_ in List.objects.all():
        items = list_.item_set.all()
        texts = set()
        for ix, item in enumerate(items):
            if item.text in texts:
                item.text = "{} ({})".format(item.text, ix)
                item.save()
            texts.add(item.text)

class Migration(migrations.Migration):
    dependencies = [
      ("lists", "0004_item_list")
    ]

    operations = [
        migrations.RubPython(find_dupes)
    ]

重新创建以前的迁移

使用 makemigrations 重新创建以前的迁移,确保这是第 6 个迁移,而且还明确依赖于 0005,即那个数据迁移。

D.4 一起测试这两个迁移

现在可以在线上数据中测试了:

cd deploy_tools
fab deploy:host=watch@watch0.top
[...]

还要重启服务器中的 Gunicorn 服务:

sudo restart gunicorn-watch0.top

然后可以在过渡网站中运行功能测试。

D.5 小结

这个练习的主要目的是编写一个数据迁移,在一些真实的数据中测试。当然,这只是测试迁移的千万种方式之一。你还可以编写自动化测试,比较运行迁移前后数据库中的内容,确认数据还在。也可以为数据迁移中的辅助函数单独编写单元测试。你可以再多花点时间统计迁移所用的时间,然后实验多种提速的方法,例如,把迁移的步骤分得更细或更笼统。

但这种需求很少见。根据作者的经验,使用的迁移,99% 都不需要测试。

关于测试数据库迁移

  • 小心引入约束的迁移

    • 99% 的迁移都没问题,但是如果迁移为现有的列引入了新的约束条件,一定要小心。

  • 测试迁移的执行速度

    • 一旦项目变大,就应该考虑测试迁移所用的时间。执行数据库迁移时往往要下线网站,因为修改模式可能要锁定数据表(取决于使用的数据库种类),直到操作完成为止。所以最好在过渡网站中测试迁移要用多长时间。

  • 使用生产数据的副本时要格外小心

    • 为了测试迁移,要在过渡网站的数据库中填充与生产数据等量的数据。如果直接转储生产数据库导入过渡网站的数据库中,一定要十分小心,因为生产数据中包含真实客户的详细信息。

Previous附录 C 使用 Ansible 配置服务器

Last updated 5 years ago

Was this helpful?

是一种特殊的迁移,目的是修改数据库中的数据,而不是变更模式。应用完整性约束之前,先要执行一次数据迁移,把重复数据删除。具体方法如下:

数据迁移的详情参阅 。下面是修改现有数据的方法:

数据迁移
Django 文档