It can't work because of not satisfied std::error::Error trait, when I use thiserror (#[from] ceresdb-client-rs::Error), I have to impl From<ceresdb_client_rs::Error> for ExbotError

use thiserror::Error;

pub type Result<T> = std::result::Result<T, ExbotError>;

#[derive(Error, Debug)]
pub enum ExbotError {
    #[error("ceresdb client error: {0:?}")]
    CeresDb(#[from] ceresdb_client_rs::Error),
}

//impl From<ceresdb_client_rs::Error> for ExbotError {
//fn from(err: ceresdb_client_rs::Error) -> Self {
//ExbotError::CeresDb(err)
//}
//}

Signed-off-by: Ruihang Xia [email protected]

Display QueriedRows in csv format. An example:

t,tsid,name,value,,
Timestamp(Timestamp(1651737067000)),Int64(-6317898613073581291),String(StringBytes(b"ceresdb")),Double(100.0),,

Rationale for this change

Now, the rust client can only be used for ceresdb of standalone mode. We should modify it for serving ceresdb of cluster mode.

What changes are included in this PR?

• Refactor project's directory organization for clearer structure.
• Add router to fetch endpoint for metrics.
• Add cluster implementation for client.

Are there any user-facing changes?

Users can now use client to access ceresdb of cluster mode.

How does this change test

CI itself.

Which issue does this PR close?

Closes issue 240 in the main repo. Closes #16

Rationale for this change

Tonic is a native gRPC implementation with these pros:

• Native, and safety.
• More users (compare to grpcio)
• Lower memory consumption

What changes are included in this PR?

1. Remove the dependency: grpcio.
2. Reimplement the RpcClientImpl.
3. Refactor RpcClientImplBuilder and renamed to RpcClientImplFactory.
4. Refactor the hierarchy of the codes. DbClient Implementations for both the standalone mode and cluster mode was made to depend on the underlying InnerClient.

Are there any user-facing changes?

This PR just restructures the source code so as to improve maintainability without altering functionality.

How does this change test

Pass the existing CI.

Problem

Currently, the query response won't contain schema information if no data is found, which will lead to failure in parsing schema.

Proposal

Avoid parsing schema if no data is found.

Rationale for this change

Refactor client interface to Improve usability.

What changes are included in this PR?

Change req's type in DbClient::query from ceresdbproto::QueryRequest to QueryRequest, and impl From for ceresdbproto::QueryRequest.

Are there any user-facing changes?

Users can use this client independently without explicitly introducing ceresdbproto crate.

How does this change test

By existing UT

Which issue does this PR close?

Closes #25

Rationale for this change

Now, error in our client doesn't implement std::error::Error. It may lead to problem while interact some error handling crates such thiserror(see #25 ).

What changes are included in this PR?

Use thiserror to standardize our error type.

Are there any user-facing changes?

None.

How does this change test

Test by ut.

Rationale for this change

Now, fix the error mentioned in title.

What changes are included in this PR?

• fix error.

Are there any user-facing changes?

None.

How does this change test

Check by manual test with CeresDB.

After the ceresdbproto has been migrated to tonic toolchain, we hope the client should follow such a migration to avoid use of grpcio.

More information can be found in: https://github.com/CeresDB/ceresdb/issues/240

Problems

Now the CeresDB server provides routing information by route gRPC method but the client has not supported this api yet, that is to say, the client can't be used for a CeresDB cluster.

Proposal

• Retreive routing information about the query/write requests;
• Cache the routing inforamtion in the client;
• Able to evict the invalid routing entries;

Additional Context

Java client can provide a good example about the propasal.

This way downstream consumer like ceresdb-client-py only have to depend on ceresdb-client-rs, never gonna mix up different versions of common_types crate.