I hereby agree to the terms of the CLA available at: https://databend.rs/policies/cla/

Summary

fix:

• issue [improvement] store client factory #1869

Changelog

• Improvement

Summary

• Crate common-fligts has been renamed to store-api-sdk

  • To emphasize that one can use this crate to utilize store apis.
  • A factory is provided like this:

   #[derive(Clone)]
   pub struct StoreApiProvider {
     ...
   }
  
   impl StoreApiProvider {
      pub fn new(conf: impl Into<StoreClientConf>) -> Self
  
      pub async fn try_get_meta_client(&self) -> Result<Arc<dyn MetaApi>> 
      pub async fn try_get_kv_client(&self) -> Result<Arc<dyn KVApi>>
      pub async fn try_get_storage_client(&self) -> Result<Arc<dyn StorageApi>>
   }
  

  since common-xxxx are not supposed to depend on crate query::configs::Config, we can not use Config directly in store-api-sdk.

  A converter form Config to StoreClientConf

   impl From<&Config> for StoreClientConf ...
  

  is provide in crate query.

• The mock of KVStoreApi -- LocalKVStore is provided by crate store-api-sdk

  • LocalKVStore has been changed to a simple in-memory implementation
    The idea of re-use code of store-state-machine is great, but, currently,

    1. there are circular dependencies if we place StateMachine based LocalKVStore into crate store-api-sdk
    2. also, make common-xxx depend on crate store is not a good idea IMO
    3. let's rollback to the former implementations after the dependency issues resolved

  • The mock is provided as a part of a non-default feature of crate store-api-sdk
    crates that depend on it, like common-management should declare an extra dev dependency in cargo.toml, like this

          [dev-dependencies]
           common-store-api-sdk= {path = "../store-api-sdk", features= ["mocks"]}
    

    It has been added to the cargo.toml of crate common-management

  • management::namespace::local_kv_store_test.rs now using common_store_api_sdk::mocks::LocalKVStore

• UserMgr Api changed

  to runtime dispatching style:

   pub struct NamespaceMgr {
     kv_api: Arc<dyn KVApi>,
   }
  
   impl NamespaceMgr {
     pub fn new(kv_api: Arc<dyn KVApi>) -> Self {
       NamespaceMgr { kv_api }
     }
    ...
   }
  

  Since, the provider method signature fn try_get_kv_client(&self) -> Result<Arc<dyn KVApi>> indicates that the caller site does not know the concrete type of which implemented KVApi.
  Previous static dispatching style of using Store Apis can also be implemented but seems to be not user-friendly (to compose the components).
  Same modification goes to UserMgr

• Store Apis slightly changed

  trait StoreApis are removed since we are going to split the Store services into multiple services.

  KV/Meta/Apis no longer take &mut self, since they are all wrapped in Arc while being passed around.
  Instead, the flight client is cloned(which is lightweight, according to this), before calling the flights API.

Related Issues

Fixes #1869

Test Plan

Unit Tests

Stateless Tests