Public API RFC#2
Conversation
Signed-off-by: Xiaoguang Sun <sunxiaoguang@zhihu.com>
| description = "The rust language implementation of TiKV client." | ||
|
|
||
| [lib] | ||
| name = "tikv_client" |
There was a problem hiding this comment.
mostly, we name our Go library as ticlient, maybe we can use the same name here. :-)
There was a problem hiding this comment.
I had a little concern what if there are other storage system built on top of TiKV and we want to implement a Rust client for it as well?
There was a problem hiding this comment.
Although it's probably too early to say that. But I really pictured a day in my mind that we could build a distributed file system or maybe timeseries database on top of TiKV. And for the nature of it's protocol complexity, it's likely a dedicated client is preferred.
There was a problem hiding this comment.
Can't believe that after more than a decade, HDFS probably wins in ecosystem but still loses in scalability due to HA NameNode architecture. Even Google's initial GFS has something better than HDFS. Although there are federation support but it sounds better to have a clustered NameNode natively which can be built on top of TiKV.
There was a problem hiding this comment.
@siddontang I can only see TiClient used twice in TiDB's code: https://github.com/pingcap/tidb/search?q=TiClient&unscoped_q=TiClient.
Also in the name of one test file https://github.com/pingcap/tidb/blob/cb03f2bec151033a38dfd17715a42cf3728b0541/store/tikv/ticlient_test.go
I think using a different name than tikv_client risks the user not understanding what this is for. ticlient is ambiguous and could mean tidb or tispark or something else.
| use {Key, KeyRange, KvFuture, KvPair, Value}; | ||
|
|
||
| pub trait Raw { | ||
| fn get<K, C>(&self, key: K, cf: C) -> KvFuture<Value> |
There was a problem hiding this comment.
Maybe we can borrow the key here? This would possibly save the caller a vec.clone().
There was a problem hiding this comment.
The underlying grpc request is going to move this key anyway. And I found there is a suggestion in API Guideline saying if an argument is going to be moved, it's better to make it clear on function signature instead of making a clone/copy inside the implementation.
Signed-off-by: Xiaoguang Sun <sunxiaoguang@zhihu.com>
Signed-off-by: Xiaoguang Sun <sunxiaoguang@zhihu.com> Signed-off-by: Xiaoguang Sun <sunxiaoguang@zhihu.com>
Signed-off-by: Xiaoguang Sun <sunxiaoguang@zhihu.com>
sunxiaoguang
force-pushed
the
public_api_rfc
branch
from
8c3f691 to
46a8d05
Compare
3 participants
This is a pull request helping us to make comments on public API