SQLite 爬坑记

作为从零开始的Web开发人员,在项目开发中总是遇到这样那样的坑,其中数据库的坑最多。由于在功能完善过程中需要变换频繁,不可避免地要更改DB Schema,不过我都是能不改尽量不改。逃不过时,只能硬着头皮刚。

故事是这样的,我要把两个表中的某两列的类型由字符型改成列表。在数据库值类型中就是BLOB,ORM中叫做PickleType。数据库使用SQLite,ORM使用SQLAlchemy,并使用基于Alembic的自动化迁移工具,于是就开始了。

Round 1

直接开搞

migrate。。。咦?怎么脚本没生成?Google之,Alembic不能探测类型变化。

OK,我手动写个好了吧,upgrade。。。报错!ALTER TABLE 不支持改变类型。

Round 2

好在这两列也是新加不久,并不十分重要,于是我想到了,我删了再加可以了吧?

downgrade。。。报错!drop column也不支持。

Round 3

看来只能放弃自动化迁移了,Google一番,找到一个drop columnworkaround:复制一个去掉该列的新表,并覆盖原表。

create table temp as select col1,col2... from old_table;
drop table old_table;
alter table temp rename to old_table;

这时候再migrate,正确生成了脚本:

add_column ......
add_column ......
create_foreign_key ...

嗯。。看上去不错,最后一行是。。新表没有带上外键信息。

upgrade。。。报错!create_foreign_key失败!SQLite也不支持,无语了,不愧是Lite,怎么不去屎?

进数据库看看,新的列已经加上了,查了一下已有的关联列,没啥问题啊?

LEAVE IT ALONE!管它了,跑起来,新增一行数据,Beng shaka laka!原来缺少外键信息已有数据没问题,新增就出问题,还加了一行死数据,删不掉还(没有生成主键)。

Round 4

从备份恢复数据库。Google外键问题,得到答案是别无他法,只能重新建表再复制数据。

alter table old_table rename to temp;
create table old_table (...);
insert into old_table select col1,col2,... from temp;
drop table temp;

重新建立migration文件夹,运行测试,一切正常。

总结:

备份备份备份,折腾数据库之前一定要备份!不然就等着哭吧。代码用版本控制管理,数据库备份,我才有底气胡搞一通。

特别感谢Google以及StackOverflow提供的帮助。

珍爱生命,请用MySQL。

最后编辑于
知识共享协议
本作品采用CC-BY-SA许可.