Struct bigtable_rs::bigtable::BigTableConnection

pub struct BigTableConnection { /* private fields */ }

For initiate a Bigtable connection, then a Bigtable client can be made from it.

Implementations

impl BigTableConnection

pub async fn new( project_id: &str, instance_name: &str, is_read_only: bool, channel_size: usize, timeout: Option<Duration> ) -> Result<Self, Error>

Establish a connection to the BigTable instance named instance_name. If read-only access is required, the read_only flag should be used to reduce the requested OAuth2 scope.

The GOOGLE_APPLICATION_CREDENTIALS environment variable will be used to determine the program name that contains the BigTable instance in addition to access credentials.

The BIGTABLE_EMULATOR_HOST environment variable is also respected.

channel_size defines the number of connections (or channels) established to Bigtable service, and the requests are load balanced onto all the channels. You must therefore make sure all of these connections are open when a new request is to be sent. Idle connections are automatically closed in “a few minutes”. Therefore it is important to make sure you have a high enough QPS to send at least one request through all the connections (in every service host) every minute. If not, you should consider decreasing the channel size. If you are not sure what value to pick and your load is low, just start with 1. The recommended value could be 2 x the thread count in your tokio environment see info here https://docs.rs/tokio/latest/tokio/attr.main.html, but it might be a very different case for different applications.

pub fn new_with_token_provider( project_id: &str, instance_name: &str, is_read_only: bool, channel_size: usize, timeout: Option<Duration>, token_provider: Arc<dyn TokenProvider> ) -> Result<Self, Error>

Establish a connection to the BigTable instance named instance_name. If read-only access is required, the read_only flag should be used to reduce the requested OAuth2 scope.

The authentication_manager variable will be used to determine the program name that contains the BigTable instance in addition to access credentials.

channel_size defines the number of connections (or channels) established to Bigtable service, and the requests are load balanced onto all the channels. You must therefore make sure all of these connections are open when a new request is to be sent. Idle connections are automatically closed in “a few minutes”. Therefore it is important to make sure you have a high enough QPS to send at least one request through all the connections (in every service host) every minute. If not, you should consider decreasing the channel size. If you are not sure what value to pick and your load is low, just start with 1. The recommended value could be 2 x the thread count in your tokio environment see info here https://docs.rs/tokio/latest/tokio/attr.main.html, but it might be a very different case for different applications.

pub fn new_with_emulator( emulator_endpoint: &str, project_id: &str, instance_name: &str, is_read_only: bool, timeout: Option<Duration> ) -> Result<Self, Error>

Establish a connection to a BigTable emulator at [emulator_endpoint]. This is usually covered by Self::new or [Self::new_with_auth_manager], which both support the BIGTABLE_EMULATOR_HOST env variable. However, this function can also be used directly, in case setting BIGTABLE_EMULATOR_HOST is inconvenient.

pub fn client(&self) -> BigTable

Create a new BigTable client by cloning needed properties.

Clients require &mut self, due to Tonic::transport::Channel limitations, however the created new clients can be cheaply cloned and thus can be send to different threads

Trait Implementations

impl Clone for BigTableConnection

fn clone(&self) -> BigTableConnection

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.