ORM数据库迁移工具

2020-05-15 12:35:06

为什么是SQL呢?我已经将近十年没有接触过MongoDB世界了(真是松了一口气)。卡桑德拉从来没有真的穿过我的路。任何理智的团队都有自己的Elasticsearch迁移工具,叫做从头开始创建所有索引,这里没有什么有趣的可说的。我唯一接触过的另一个数据库是Datonomic,他们有一些关于迁移的非常有趣的事情要说,我不会对此发表评论。

不管怎样,说到这个话题。为什么会存在基于ORM的迁移工具?让我们看一组项目本身的描述来寻找线索:

Django:迁移是Django传播您对模型所做更改(添加字段、删除模型等)的方式。添加到您的数据库架构中。它们被设计成基本上是自动的,但你需要知道什么时候移民,什么时候运行,以及你可能会遇到的常见问题。

Ruby onRails:迁移是一种方便的方式,可以随着时间的推移以一致和简单的方式改变您的数据库模式。它们使用Ruby DSL,这样您就不必手动编写SQL,从而允许您的模式和更改独立于数据库。

我曾亲自使用Django迁移和浏览文档来实现其他一些工具:Alembic、RoR迁移、Sequelize、TypeORM。

数据库独立性对于一些Django风格的应用程序当然很有用。它们本质上是定义它们自己的模型并可以在新版本中更新它们的库。我想到的是用户管理库,比如django-allauth或python-Social-auth。如果没有内置的迁移,我们将不得不阅读它们的更改日志,并通过手形的穴居人来应用模式更改。

我现在认为,任何Django风格的应用程序只对几个月内组装在一起的短项目有用。在长期项目中,他们通常遇到的障碍比帮助的要多得多。

绝大多数Web应用程序和产品都运行在一个数据库上,不要从Oracle切换到MySQL,再切换到PostgreSQL,然后再切换回来。

这些工具致力于自动生成迁移。这个过程是这样的:阅读文档,在模型声明中添加一个字段,运行一些命令,然后砰!我们已经完成了迁移,现在不必编写ALTER TABLE TABLE CREATE COLUMN,所以我用一分钟来写一行,用一两个小时来阅读文档和使用这个新工具。令人着迷的体验,我希望它至少能为我们节省更多的时间。

一周后,我重命名了一些字段或表,现在该工具想要删除该字段并创建另一个字段。我想我必须回去阅读更多的文档,才能记住如何指示工具实际重命名一个字段,而不是丢弃它并创建一个新字段。我真的希望避免那么多地编写ALTER TABLE吗?

几周过去了,我对工具有了更多的经验,记住了命令和要传递的标志,我学会了如何重命名这个和那个,花了一些时间调试我的迁移。在一个简单的ALTER TABLE之上的小时数和小时数。

现在,我需要在一个大型数据库上进行一些非常重要的迁移。例如,它是创建几个字段、用信息填充它们、创建附加索引、删除旧字段和索引的组合。在这种情况下,我通常将Postgres shell打开到本地数据库,打开一个事务,然后像REPL中的代码一样进行迁移。开始,然后创建一些列,用信息填充它们,选择以检查它是否正确。不,在更新过程中搞砸了一些案例,丢失了大约三分之一的相关信息。没问题,请回滚,粘贴工作部分,然后重试。

就这些自动化工具而言,在我完成所有这些工作之后,我必须重新阅读它们相当大量的文档,因为我忘记了一些东西,并且将SQL移植到了它们的语法中。或者,我现在应该直接使用原始SQL吗?从一开始就使用这个工具的意义是什么?

然后,我们将还不太了解SQL的初级成员添加到团队中。通过该工具,EasierTask是自动化的,他们只需阅读几个小时的文档,而不需要学习如何用SQL编写实际的ALTER TABLE,以及它可以在事务内回滚等等。

而现在,当低年级学生面临更复杂的问题时,他们完全缺乏发展迁移的技能,需要攀登的墙要陡峭得多。因此,他们坐在电脑前,盯着文档看了几个小时,这本来是一项现在应该可以接近的任务。

另一件事是,许多工具都有降级迁移。降级移民是个谎言!我删除了一个带有NOT NULL的列,现在怎么办?迁移现在是不可逆转的。如果我真的需要在生产环境中恢复可逆迁移,我将编写另一个向前迁移。我在十多年的时间里做到了零次。

在开发期间,我可以切换具有不同模式的分支,它们可能是不兼容的。当然,然后我必须手动进行向后迁移,甚至从跟踪表中删除一行。在过去的五年里,我这样做过几次。无处不在的降级迁移能为我节省这5分钟吗?毋庸置疑,这种不兼容性通常源于不可逆转的变化,比如删除NOT NULL列,而迁移工具只会发出不可逆转的错误。

另一个次要问题是,有时迁移需要很长时间。不是一秒或两秒-它可以在生产过程中持续几个小时。我不希望此迁移在我的部署过程中自动开始(我的配置项会认为它已死亡,等等),但它应该是所有迁移的常规部分,因此在本地开发人员安装时,这些迁移只需按常规进行迁移即可。提取SQL脚本的一部分并单独运行,要比提取用Python编写的迁移脚本的一部分并单独运行要容易得多。

几年前,当我继承了一个带工作迁移的Django项目时,我已经用了几个月的疯狂,然后又换回了一个简单的基于SQL的系统。

虽然这些工具使最简单的案件自动化,但它们使更复杂的案件变得更加困难。不幸的是,这是姜戈地区非常常见的陷阱,我听说RoR也差不多。

我个人使用一种名为Nomad的简单工具。我认为任何支持纯SQL迁移、迁移之间有依赖关系并且不需要写下级别的工具都是可以接受的。