reusee
reusee
Both this issue and #665 can be resolved by exposing a config for wrapping transport.Trans instances.
This feature is being tracked in https://github.com/matrixorigin/matrixone/issues/3431
https://github.com/reusee/matrixone/commit/26371a571ae8f97fb2581aacd86b8ee800aec14f I made a proposal for further discussion
This is fully implemented. Related changes: https://github.com/matrixorigin/matrixone/commit/b2eefef95b79ddfd17e926ead185a312750f80d9 https://github.com/matrixorigin/matrixone/commit/670136a87fe71a519d748e0a5e31132061036be1 https://github.com/matrixorigin/matrixone/commit/730de8bee3a4e0277fce4d761fd53d4ef1670117 https://github.com/matrixorigin/matrixone/commit/3ffbdf3a171b7819a7db65bf21bfd692689fc47a https://github.com/matrixorigin/matrixone/commit/0d89c5d454944802073f1a338965e16ccd493845 https://github.com/matrixorigin/matrixone/commit/610c908fea6ab125ca1c97fa650a414e6b616aea
@fengttt I think this one includes the remaining CN works: https://github.com/matrixorigin/matrixone/issues/3931
Both FILE_NOTIFY_CHANGE_LAST_ACCESS and FILE_NOTIFY_CHANGE_LAST_WRITE will emit FILE_ACTION_MODIFIED event. I think there should be an option to disable last access time triggering Write op event.
Go 2 transition 这个提案就是讲如何处理不兼容的语言或者标准库的改动的。 1.12 的 go.mod 已经引入了语言版本的标记，就是 "go 1.xx" 这一行，标明这个模块最低的版本要求。不同的模块，可以使用不同的语言版本去编译，所以并不会有“打破Go1的兼容性承诺”出现。Background 这一段也明说了 > Among the goals for the Go 2 process is to consider changes to the language and standard...
就你这个例子，按照这个提案的做法，在同一个程序里，可以是新模块用新的导出规则，旧模块用旧的导出规则，并不会破坏go1兼容性。这个提案的初衷就是让新旧语言可以共存于一个程序里，而不是一刀切开。go1的兼容性承诺是旧代码不会被break，这个提案目的就是不论语言怎么改，旧代码都不用改。 对于 ABI，也有相关的提案：https://github.com/golang/proposal/blob/master/design/27539-internal-abi.md 和源码层面的兼容类似，这个提案也是要实现新旧 ABI 的兼容。现在的 ABI 是有事实标准的，而且将会被称为 ABI0。后续所有 ABI 层面的改进，都不会破坏对 ABI0 的兼容。一个程序某些模块遵循旧 ABI 写汇编，另外一些模块遵循新 ABI，是允许的。 这些都是逐渐演进的过程，没有什么改朝换代，这和其他语言的发展方式是不一样的。
https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md#language-removals 这一段就是讲删除一个语言特性之后，仍然保证旧代码可以继续使用。很显然，新版本删除了某个语言特性，那旧版本语言就不可能是新版本语言的子集。旧代码可以继续使用，那就是兼容了，所以兼容并不代表旧版本必须是新版本的子集。
确实啊，Go 2 transition 提案最后一段，就是这个意思。go 2 这个名称确实会给人一种不兼容的新语言的感觉，但实际不会不兼容，这只是一种泛指。特性会逐渐加，就像 error values 大概率加到 1.13，那 1.13 是否应该改叫 2.0 呢？它都实现了部分 go 2 draft 里的东西了。 所以你认为 2020 才开始 go2 开发是不对的，已经开始开发了。go1 的支持也不会在 2030 终止，编译器会一直支持现有的代码。