Closed heroyf closed 1 year ago
老哥,"github.com/gotomicro/ekit/slice" 这个包的引用需要将 gotomicro 改成 ecodeclub
v0.0.6 module 声明的还是gotomicro,我的理解是这里不做replace,等ekit下次版本迭代更名后,统一在go.mod中做replace 目前看还有很多其他地方import的是gotomicro
应该全部都改成了 ecodeclub,你试试更新代码?
哦哦,是 ekit 的啊。ekit 的暂时保留 gotomicro。要等我发布新的 ekit 版本之后再来切换。
Merging #174 (2679e84) into dev (8996c2e) will decrease coverage by
0.15%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## dev #174 +/- ##
==========================================
- Coverage 81.46% 81.31% -0.15%
==========================================
Files 32 32
Lines 2600 2569 -31
==========================================
- Hits 2118 2089 -29
+ Misses 403 402 -1
+ Partials 79 78 -1
Impacted Files | Coverage Δ | |
---|---|---|
sharding_select.go | 54.24% <100.00%> (-3.38%) |
:arrow_down: |
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
对于哈希来说,是广播;但是对于范围分库分表来说,则不是广播,这种算法可以通过对范围的上界和下界进行取反之后计算得到。
@heroyf 这个合并请求你暂时只修复一下那个 BUG,NOT 查询的话,可能要重新设计
对于哈希来说,是广播;但是对于范围分库分表来说,则不是广播,这种算法可以通过对范围的上界和下界进行取反之后计算得到。
想了一下这个,如果对于范围分库分表,是不是依旧还是广播,而不是简单对于上界下界取反? 例如按照UserId的范围进行区分(某一种分片算法实现>=500在table_2,<500在table_1),那么NOT(user_id = 510)也是需要查询两张表。所以对于NOT目前这两种情况都是广播,最终要解决的就是广播情况下的查询优化问题
这里可能还需要再深入考虑一下是否还有其他场景
@heroyf 这个合并请求你暂时只修复一下那个 BUG,NOT 查询的话,可能要重新设计
好的,这个我先修复对于非分片键等值查询结果为空的情况
fix: hash和shadow_hash 分片在对非分片键查询时返回为空的问题修复
feat: NOT支持(暂不在在合并中支持)