feature: 分库分表：ShardingUpdater 实现

[Stone-afk]

剩下的测试继续补

[codecov[bot]]

Codecov Report

Merging #203 (7fa582e) into dev (472250f) will increase coverage by 0.13%. The diff coverage is 86.36%.

@@            Coverage Diff             @@
##              dev     #203      +/-   ##
==========================================
+ Coverage   85.37%   85.50%   +0.13%     
==========================================
  Files          47       48       +1     
  Lines        3535     3692     +157     
==========================================
+ Hits         3018     3157     +139     
- Misses        410      423      +13     
- Partials      107      112       +5     

Impacted Files	Coverage Δ
builder.go	85.96% <ø> (ø)
update.go	82.96% <83.33%> (+0.25%)	:arrow_up:
sharding_builder.go	84.21% <84.21%> (ø)
sharding_update.go	85.63% <85.63%> (ø)
sharding_insert.go	78.32% <95.65%> (+0.54%)	:arrow_up:
insert.go	92.94% <100.00%> (+0.17%)	:arrow_up:
sharding_select.go	73.64% <100.00%> (-3.20%)	:arrow_down:

... and 1 file with indirect coverage changes

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[longyue0521]

请帮忙看看这种代码组织方式是否优雅

@flycash

如果eorm的定位就是支持分库分表的orm,现在的组织方式挺好的(可以考虑将ShardingBuilder及其测试可以单独拆出文件sharding_builder.go和sharding_builder_test.go)

如果打算拆出一个独立的分库分表项目,现阶段erom和未来的erom-sharding共享着某些数据模型的及错误信息的(internal/errs, builder中的unexported共享数据类型等),随着功能的不断增多,等拆的时候可能会很麻烦甚至我们都不确定哪些该删哪些该保留,最后只能全量拷贝.

是不是可以先在eorm根目录下建立一个sharding目录包含全部分库分表相关代码,为拆分做一下准备.

即使不拆,用户使用时可以直接

import (
    "github.com/ecodeclub/eorm/sharding"
)

到拆分之时,只需要将sharding内的代码提交到erom-sharding仓库,然后直接删除eorm中的sharding目录即可完成项目分离.

[flycash]

目前来看，的确做不到按照 DB 维度来发送请求。 有两个问题：

• 至今在尝试使用 multiStatements=true 选项的时候，依旧会出错；
• 即便可以使用 multiStatements，也难以教会用户在这里必须要指定 multiStatements，而我也不想我们自己拼接一个

所以改成一个表一个

[Stone-afk]

mark

[flycash]

我重构 insert 的时候顺手微调一下