alembic 问题一大堆，改个字段名直接删了重新建，改字段类型迁移不生效，伤透了心，手动 ddl 了

@lolizeppelin 那什么，突然发现自己昨天评论不太合适，还是好好评论，当作把自己知道的表达出来的一种途径吧

@lolizeppelin mysql 的 json 都是后面版本才支持的，你以为呢。人挪活，树挪死，sqlite 没有 json 字段你怎么支持嘛。sqlite 作为单元测试只是减少运维工作量，不至于哪天单元测试用的数据库挂了，你 jenkins 构建跑不过。
但其实也不一定奸杀运维工作量，比如你用的是 flask，你完全可以在单元测试脚本里面，把配置的数据库连接的数据库改成其他数据库，例如 unit 而不是 develop，这样还是一台 mysql 服务器，但是单元测试一个库，其他的环境用其他的库，根本不会相互影响，我就不信你们只有本地和生产，没有测试环境的数据库。

git rebase 的应用场景还包括，合并提交，比如我的 feature 变成了 1-2-3，2-3 是一次任务的两次提交，要合并成一个，怎么办，可以先 git reset soft 到 1 这个位置，然后把暂存区的 commit 一次，变成 4，就合并成功了。也可以 git rebase 。
至于 bug，一般是先从 develop 分出来一个 bug 分支，然后修改，一次提交，合到 develop，这时候 feature 分支原来也是从 develop 分出来的，肯定也有这个 bug，所以要把这个 bug 的提交也再 feature 上面重放一次，记住是重放，提交哈希值是不一样的，一般用 cherry-pick 。当然你也可以 git rebase 基于最新的 develop，让那个 bug 的提交插入到 develop 的提交和你的 feature 提交之间

我的应用场景是这样。我们不允许本地直接提交 develop 分支，都是拉下来 develop 分支，创建 feature 分支，然后 push 到远程 feature 分支，然后远程提 pr 要求合并到 develop，给别人 review 。这时候就有个问题了，我不能在别人 review 的时候 block 在那里啊，如果幸运的话，我的 feature 分支通过了，会合并到 develop 分支，所以我本地得从 feature 分支 checkout 一个 feature2，然后继续开发。
问题来了，如果我的远程的 feature 分支要修改，比如 feature 现在是 1-2，远程也是 1-2，但我要修改本地变成 1-2-3，但是这个 feature 就变成了 2-3 两次提交，一次任务两次提交，不好在 web 界面对比和 develop 的变化，所以我要在本地合并 2 、3 提交，变成 4，就是 1-4 了，这时候远程还是 1-2，没办法，git push origin feature -f 强制提交。
又有问题来了，feature2 刚刚还是切换过来还是 1-2 呀，这可怎么办，如果 git merge feature 就分叉了，这时候就可以用 git rebase 让 feature2 以 feature 为基，变成 1-4-2’，看起来就像是从最新的本地 feature 分支切换过来，又加了一次提交，当然这个 2‘已经不是原来的 2’了，hash 值也不一样了。这样的好处是，如果 feature 远程合并到了 develop 远程，develop 提交记录就是 1-4，你的 feature2 再合过去就不会有冲突了

1.git rebase 是变基操作，feature 1-2，bugfix 从 feature 分出来，提交是 1-2-3，这时候切换回 feature，再提交一个，变成 feature 1-2-4
这时候如果在 feature 合并 bugfix 会变成 1-2-（ 3，4 ）-5，提交历史是双线，不是很清晰，怎么办呢，我们可以让 feature 分支基于 bugfix 分支，这就是 git rebase，过程是首先找到两个分支的共同祖先 1-2，然后再 feature 分支上 copy3 提交，然后提交 4`这 4‘和 4 的 hash 值不一样了，只是修改一样而已。然后当然如果 3-4 冲突了，还是要解决冲突，但最后的结果还是 1-2-3-4`，就是一条直线了，而且和提交时间无关，就是把 bugfix 的不同提交插入 feature 分支的 2 后面
2.解决冲突可配合 pycharm 使用，可视化更加方便，否则文件中一堆》》》

结合 pycharm 的 git rebase 可视化解决冲突食用，更加愉快

那你就单独搞一个 mysql 做测试用的数据库，sqlite 文件数据库只是方便，只有一个文件或者是只是内存数据库，但不代表就一定要用这个啊

@lolizeppelin 废话，pg 和 mysql 对 json 的支持能统一吗，你老老实实用 orm，会帮你把关联表转化成 array 好吧，别乱用，你抄 openstack 单元测试的时候，怎么不抄人家的表结构设计呢

这告诉我们不要在 rdbms 用 json，老老实实关联

@flowfire 今天就是拉开窗帘的

昨晚看到这个帖子，决定早点睡。现在 7 点多，我刚起，昨晚 10 点睡的，我是不是睡觉时间有点长，可还是打哈欠

不用

@ropon RESTFUL_JSON = dict(ensure_ascii=False)
就可以了

ensure_ascii=False

@RedBeanIce 然而还是想

@abersheeran 可惜很多人不懂，你说 django 好，绝大多数情况都会收到一句回复“但是 django 太重了”，我现在听到这句话就火大，spring 还重呢，有本事别用啊，你看多少人用？找个轻的框架是想要写 toy ？ flask 谁用谁知道！！！这框架是轻了，但是项目打了不得模块化开发？不得用上各种扩展，flask 那个扩展又是良莠不齐，真是糟心。还有哦，很多公司那个体量，就别操心高并发的事情了，就算后期访问量暴涨，不是还有 ins 公司的经验可以借鉴吗？不知道瞎搞什么。最近写 flask 真是写得心累

纯屎公司

@skenan 这个项目结构就是抄袭 django 的