Taiga 1.8 升级 1.9 折腾笔记

Taiga 是一个很有活力的开源项目管理项目,基于 Scrum 项目管理方式对项目进行管理。

这个项目更新非常多,使用的框架是 Django + AngularJS,因此免不了要经常升级以获得新的功能,因为旧的功能往往不完善,掉队之后就失去活力了。

但是对于 Django 而言,更新总不是一件容易的事情,尤其是数据库,一旦 migrate 出了问题,就会面临很复杂的数据库的问题。

官方的更新步骤说明:http://taigaio.github.io/taiga-doc/dist/setup-faqs.html#faq-maintain-update

ATTENTION! 注意一定要按照上面的官方更新步骤进行更新,(一定要 update requirements,不要自己进行 makemigrations,分支一定要使用 stable 或者 release 的 tag 版本)

由于之前没有严格按照这样来操作,导致 migration 真的出问题了,无奈之下,就只能退回 1.8,导出项目,重装 1.9,然后把项目导回去。

附件的导出导入问题

对于一个项目进行导出,会将所有的数据库字段以及附件 Blob 都以 json 的方式导出,而事实上附件在部署中不是存放在数据库的,而是存放在 ~/taiga-back/media/attachment 里面的,事实上,~/taiga-back/media 的整个目录都应该重点备份。

问题是,导出了项目的一个超巨大的 json 之后,再导进去,会出现下面这些问题:

  1. 项目的编号跟原来不一样了;
  2. 附件会重新生成进去,但是,sha1 不一样,因为莫名原因 taiga 会将文件截断成 8192B,多出来的就不见了,所以同样的文件会多了一份损坏的文件,存放在另一个地方。
  3. 数据库里面有个表 attachments_attachment,这个表里面的 name 文件名字段会从中文变成拼音
  4. 嵌入在 issue 和 wiki 里面等等的附件连接,还是链接向原来好的文件,理论上保持即可

所以,导入之后,目测用户关系都还好,但是附件就感觉完全崩坏了,必须手动修复。

于是,修复的办法就包括:

  1. 把数据库里面的文件名和路径都定位回原来的路径;
  2. 把新创建出来的 8192 的文件杀掉;

处理方法

1. 修改数据库的内容

经过反复观察,使用 create_date 进行对账是最靠谱的,但是导出之后,毫秒级别的时间被切割,所以稍为调整一下。

其次,1.9.0 添加了一个字段 sha1,经过验证,这个字段就是附件文件的 sha1,要想办法计算并插入。

然后 name 字段需要拿回原来的字段值。

我们首先将旧的正常数据库里面附件表里面的内容抓出来,放到 excel 表里面:

select concat(to_char(created_date, 'YYYY-MM-DD HH24:MI:SS'), '+08') created_date,
    attached_file, name, size
from attachments_attachment
order by created_date

接下来我们把 attached_file 这一列单独粘贴到服务器的一个文件里面:

vim ~/attached_file.csv

然后我们把这些文件的 sha1 计算出来:

cd  ~/taiga-back/media
sha1sum $(cat ~/attached_file.csv) | cut -c -40 > ~/attach_file_sha1.csv

然后合并在一起,用 excel 整理成这个样子:

update attachments_attachment set attached_file = ' attachments/3/0/8/f/d84dea9e95d532913f7c094913b3f4bd166c43150539e6d8951805138dcb/ge-si-xie-guan-wang-gai-ban-xiu-gai.jpg    ', name = ' 个私协官网改版(修改).jpg ', size='   337559  ', sha1='   8353d4df7e9a7f2470be2d419399a23b6b67490c    ' where created_date = '    2015-05-11 21:27:35+08  ';
update attachments_attachment set attached_file = ' attachments/8/a/1/9/c0f9766445f464e736b9072608c44825d3ac6b59882fe471c689aeec3b34/le-cong-ge-si-xie-4.jpg    ', name = ' 乐从个私协-4.jpg ', size='   113196  ', sha1='   ec48db6304e8b760815a8ff955357e91ad75740a    ' where created_date = '    2015-05-11 22:07:59+08  ';
update attachments_attachment set attached_file = ' attachments/b/3/f/6/514e7f0ef9cb43926e66e6e1bc7457e9ba1084eb8801fa9fbee1c321a813/yuan-ding-dan.jpg  ', name = ' 原订单.jpg ', size='   217469  ', sha1='   84fc0d1303fa2321f51a4d379e20dc4bbad32604    ' where created_date = '    2015-05-14 09:57:25+08  ';
update attachments_attachment set attached_file = ' attachments/e/7/3/a/101fc3436250fc3654cc07cba924a76a510b4357110832d4b2b9e98398be/qqjie-tu-20150520144444.jpg    ', name = ' qq截图20150520144444.jpg  ', size='   114762  ', sha1='   b6bd843574cb9d6a634666a5a1c612ce3d872f16    ' where created_date = '    2015-05-20 14:35:09+08  ';
update attachments_attachment set attached_file = ' attachments/c/b/8/c/fe32722b7574bb7c187c523f220cfee973959aba9b7d7462d93966e2cf24/qqjie-tu-20150520145753.jpg    ', name = ' qq截图20150520145753.jpg  ', size='   90608   ', sha1='   d2db7ed96f19b6fc8f3a85fb943ca741f16947b5    ' where created_date = '    2015-05-20 14:50:22+08  ';

然后用 nano 把 \t 替换没,放到 pgAdmin 上面新的数据库执行就可以更新成功了。

2. 杀掉 8192 大小的文件

当然,我们在做之前可以先把原来的 media 文件夹备份出来,然后覆盖回去,这个方法最干净彻底。

我们也可以用下面的方法来清扫附件文件:

列出所有大小为 8192 的文件:

ls -al $(find -type f) | grep 8192 | cut -c49-

将其删除:

rm $(ls -al $(find -type f) | grep 8192 | cut -c49-)

查找所有空文件夹:

find -type d -empty

一直删除直到完全拔除:

rmdir $(find -type d -empty)

后记

对于 django 的项目,一定要做好保存,尤其是中间版本的 migration 和数据库的同步保存,否则一旦 migration 和数据库的状态发生了偏离(很正常的,有时候仅仅一个依赖没装好就会这样),然后数据库就会卡在一个不可预知的半吊子状态,到时处理起来就不是一般的麻烦了。

还好,这次虽然麻烦了点,但总算完全恢复没有丢失数据,而且还把前面的 migration 错误也一并根本解决了,下次就学乖了。


【转载请附】愿以此功德,回向 >>

原文链接:https://www.huangwenchao.com.cn/2015/11/taiga-update-log.html【Taiga 1.8 升级 1.9 折腾笔记】

《Taiga 1.8 升级 1.9 折腾笔记》有1个想法

发表评论

电子邮件地址不会被公开。 必填项已用*标注