docs: simple -> unprepared, query -> statement

Still need to be adjusted in some places

docs/source/SUMMARY.md

@@ -5,7 +5,7 @@
 - [Quick start](quickstart/quickstart.md)
     - [Creating a project](quickstart/create-project.md)
     - [Running Scylla using Docker](quickstart/scylla-docker.md)
-    - [Connecting and running a simple query](quickstart/example.md)
+    - [Connecting and executing an unprepared statement](quickstart/example.md)
 
 - [Migration guides](migration-guides/migration-guides.md)
     - [Adjusting code to changes in serialization API introduced in 0.11](migration-guides/0.11-serialization.md)
@@ -15,17 +15,17 @@
     - [Authentication](connecting/authentication.md)
     - [TLS](connecting/tls.md)
 
-- [Making queries](queries/queries.md)
-    - [Simple query](queries/simple.md)
-    - [Query values](queries/values.md)
+- [Executing statements](queries/queries.md)
+    - [Unprepared statement](queries/simple.md)
+    - [Statement bound values](queries/values.md)
     - [Query result](queries/result.md)
-    - [Prepared query](queries/prepared.md)
+    - [Prepared statement](queries/prepared.md)
     - [Batch statement](queries/batch.md)
-    - [Paged query](queries/paged.md)
-    - [Lightweight transaction query (LWT)](queries/lwt.md)
+    - [Paged statement execution](queries/paged.md)
+    - [Lightweight transaction statement (LWT)](queries/lwt.md)
     - [USE keyspace](queries/usekeyspace.md)
     - [Schema agreement](queries/schema-agreement.md)
-    - [Query timeouts](queries/timeouts.md)
+    - [Statement execution timeouts](queries/timeouts.md)
 
 - [Execution profiles](execution-profiles/execution-profiles.md)
     - [Creating a profile and setting it](execution-profiles/create-and-use.md)
@@ -67,10 +67,10 @@
 
 - [Logging](logging/logging.md)
 
-- [Query tracing](tracing/tracing.md)
-    - [Tracing a simple/prepared query](tracing/basic.md)
-    - [Tracing a paged query](tracing/paged.md)
+- [Statement execution tracing](tracing/tracing.md)
+    - [Tracing a statement execution](tracing/basic.md)
+    - [Tracing a paged statement execution](tracing/paged.md)
     - [Tracing `Session::prepare`](tracing/prepare.md)
-    - [Query Execution History](tracing/query-history.md)
+    - [Statement Execution History](tracing/query-history.md)
 
 - [Database schema](schema/schema.md)

docs/source/data-types/data-types.md

@@ -5,8 +5,8 @@ to achieve seamless sending and receiving of CQL values.
 
 See the following chapters for examples on how to send and receive each data type.
 
-See [Query values](../queries/values.md) for more information about sending values in queries.\
-See [Query result](../queries/result.md) for more information about reading values from queries
+See [Statement bound values](../queries/values.md) for more information about sending values in statements.\
+See [Statement execution result](../queries/result.md) for more information about reading values after executing a statement.
 
 Database types and their Rust equivalents:
 * `Boolean` <----> `bool`

docs/source/data-types/udt.md

@@ -3,17 +3,17 @@ Scylla allows users to define their own data types with named fields (See [the o
 To use user defined types in the driver, you can create a corresponding struct in Rust, and use it to read and write UDT values.
 
 
-For example let's say `my_type` was created using this query:
+For example let's say `my_type` was created using this statement:
 ```sql
 CREATE TYPE ks.my_type (int_val int, text_val text)
 ```
 
 To use this type in the driver, create a matching struct and derive:
-- `SerializeCql`: in order to be able to use this struct in query parameters. \
+- `SerializeCql`: in order to be able to use this struct in statement parameters. \
     This macro requires fields of UDT and struct to have matching names, but the order
     of the fields is not required to be the same. \
     Note: you can use different name using `rename` attribute - see `SerializeCql` macro documentation.
-- `FromUserType`:  in order to be able to use this struct in query results. \
+- `FromUserType`:  in order to be able to use this struct in statement execution results. \
     This macro requires fields of UDT and struct to be in the same *ORDER*. \
     This mismatch between `SerializeCql` and `FromUserType` requirements is a temporary situation - in the future `FromUserType` (or  the macro that replaces it) will also require matching names.
 

docs/source/execution-profiles/create-and-use.md

@@ -27,12 +27,12 @@ let session: Session = SessionBuilder::new()
 ```
 
 ### Example
-To create an `ExecutionProfile` and attach it to a `Query`:
+To create an `ExecutionProfile` and attach it to an `UnpreparedStatement`:
 ```rust
 # extern crate scylla;
 # use std::error::Error;
 # async fn check_only_compiles() -> Result<(), Box<dyn Error>> {
-use scylla::query::Query;
+use scylla::unprepared_statement::UnpreparedStatement;
 use scylla::statement::Consistency;
 use scylla::transport::ExecutionProfile;
 use std::time::Duration;
@@ -44,10 +44,10 @@ let profile = ExecutionProfile::builder()
 
 let handle = profile.into_handle();
 
-let mut query1 = Query::from("SELECT * FROM ks.table");
+let mut query1 = UnpreparedStatement::from("SELECT * FROM ks.table");
 query1.set_execution_profile_handle(Some(handle.clone()));
 
-let mut query2 = Query::from("SELECT pk FROM ks.table WHERE pk = ?");
+let mut query2 = UnpreparedStatement::from("SELECT pk FROM ks.table WHERE pk = ?");
 query2.set_execution_profile_handle(Some(handle));
 # Ok(())
 # }

docs/source/execution-profiles/execution-profiles.md

@@ -1,6 +1,6 @@
 # Execution profiles
 
-Execution profiles are a way to group various query execution configuration options together. Profiles can be created to represent different workloads, which can be run conveniently on a single session.
+Execution profiles are a way to group various statement execution configuration options together. Profiles can be created to represent different workloads, which can be run conveniently on a single session.
 
 The settings that an execution profile encapsulates are [as follows](maximal-example.md):
 * consistency

docs/source/execution-profiles/maximal-example.md

@@ -6,7 +6,7 @@
 # extern crate scylla;
 # use std::error::Error;
 # async fn check_only_compiles() -> Result<(), Box<dyn Error>> {
-use scylla::query::Query;
+use scylla::unprepared_statement::UnpreparedStatement;
 use scylla::speculative_execution::SimpleSpeculativeExecutionPolicy;
 use scylla::statement::{Consistency, SerialConsistency};
 use scylla::transport::ExecutionProfile;
@@ -32,7 +32,7 @@ let profile = ExecutionProfile::builder()
     )
     .build();
 
-let mut query = Query::from("SELECT * FROM ks.table");
+let mut query = UnpreparedStatement::from("SELECT * FROM ks.table");
 query.set_execution_profile_handle(Some(profile.into_handle()));
 
 # Ok(())

docs/source/execution-profiles/priority.md

@@ -14,7 +14,7 @@ Priorities of execution profiles and directly set options:
 # use std::error::Error;
 # async fn check_only_compiles() -> Result<(), Box<dyn Error>> {
 use scylla::{Session, SessionBuilder};
-use scylla::query::Query;
+use scylla::unprepared_statement::UnpreparedStatement;
 use scylla::statement::Consistency;
 use scylla::transport::ExecutionProfile;
 
@@ -32,20 +32,20 @@ let session: Session = SessionBuilder::new()
     .build()
     .await?;
 
-let mut query = Query::from("SELECT * FROM ks.table");
+let mut query = UnpreparedStatement::from("SELECT * FROM ks.table");
 
-// Query is not assigned any specific profile, so session's profile is applied.
-// Therefore, the query will be executed with Consistency::One.
+// Statement is not assigned any specific profile, so session's profile is applied.
+// Therefore, the statement will be executed with Consistency::One.
 session.query(query.clone(), ()).await?;
 
 query.set_execution_profile_handle(Some(query_profile.into_handle()));
-// Query's profile is applied.
-// Therefore, the query will be executed with Consistency::Two.
+// Statement's profile is applied.
+// Therefore, the statement will be executed with Consistency::Two.
 session.query(query.clone(), ()).await?;
 
 query.set_consistency(Consistency::Three);
-// An option is set directly on the query.
-// Therefore, the query will be executed with Consistency::Three.
+// An option is set directly on the statement.
+// Therefore, the statement will be executed with Consistency::Three.
 session.query(query, ()).await?;
 
 # Ok(())

docs/source/execution-profiles/remap.md

@@ -24,7 +24,7 @@ Below, the remaps described above are followed in code.
 # use std::error::Error;
 # async fn check_only_compiles() -> Result<(), Box<dyn Error>> {
 use scylla::{Session, SessionBuilder};
-use scylla::query::Query;
+use scylla::unprepared_statement::UnpreparedStatement;
 use scylla::statement::Consistency;
 use scylla::transport::ExecutionProfile;
 
@@ -45,8 +45,8 @@ let session: Session = SessionBuilder::new()
     .build()
     .await?;
 
-let mut query1 = Query::from("SELECT * FROM ks.table");
-let mut query2 = Query::from("SELECT pk FROM ks.table WHERE pk = ?");
+let mut query1 = UnpreparedStatement::from("SELECT * FROM ks.table");
+let mut query2 = UnpreparedStatement::from("SELECT pk FROM ks.table WHERE pk = ?");
 
 query1.set_execution_profile_handle(Some(handle1.clone()));
 query2.set_execution_profile_handle(Some(handle2.clone()));

docs/source/index.md

@@ -12,15 +12,15 @@ Although optimized for Scylla, the driver is also compatible with [Apache Cassan
 
 
 ## Contents
-* [Quick start](quickstart/quickstart.md) - Setting up a Rust project using `scylla-rust-driver` and running a few queries
+* [Quick start](quickstart/quickstart.md) - Setting up a Rust project using `scylla-rust-driver` and executing a few statements
 * [Migration guides](migration-guides/migration-guides.md) - How to update the code that used an older version of this driver
 * [Connecting to the cluster](connecting/connecting.md) - Configuring a connection to scylla cluster
-* [Making queries](queries/queries.md) - Making different types of queries (simple, prepared, batch, paged)
-* [Execution profiles](execution-profiles/execution-profiles.md) - Grouping query execution configuration options together and switching them all at once
+* [Executing statements](queries/queries.md) - Creating and executing different types of statements (unprepared, prepared, batch, paged)
+* [Execution profiles](execution-profiles/execution-profiles.md) - Grouping statement execution configuration options together and switching them all at once
 * [Data Types](data-types/data-types.md) - How to use various column data types
 * [Load balancing](load-balancing/load-balancing.md) - Load balancing configuration
-* [Retry policy configuration](retry-policy/retry-policy.md) - What to do when a query fails, query idempotence
-* [Driver metrics](metrics/metrics.md) - Statistics about the driver - number of queries, latency etc.
+* [Retry policy configuration](retry-policy/retry-policy.md) - What to do when a statement execution fails, statement idempotence
+* [Driver metrics](metrics/metrics.md) - Statistics about the driver - number of executed statements, latency etc.
 * [Logging](logging/logging.md) - Viewing and integrating logs produced by the driver
-* [Query tracing](tracing/tracing.md) - Tracing query execution
+* [Statement execution tracing](tracing/tracing.md) - Tracing statement execution
 * [Database schema](schema/schema.md) - Fetching and inspecting database schema

docs/source/load-balancing/default-policy.md

@@ -2,7 +2,7 @@
 
 `DefaultPolicy` is the default load balancing policy in Scylla Rust Driver. It
 can be configured to be datacenter-aware and token-aware. Datacenter failover
-for queries with non-local consistency mode is also supported.
+for statements with non-local consistency mode is also supported.
 
 ## Creating a DefaultPolicy
 
@@ -107,7 +107,7 @@ Every `update_rate` the global minimum average latency is computed,
 and all nodes whose average latency is worse than `exclusion_threshold`
 times the global minimum average latency become penalised for
 `retry_period`. Penalisation involves putting those nodes at the very end
-of the query plan. As it is often not truly beneficial to prefer
+of the statement execution plan. As it is often not truly beneficial to prefer
 faster non-replica than replicas lagging behind the non-replicas,
 this mechanism may as well worsen latencies and/or throughput.
 

docs/source/load-balancing/load-balancing.md

@@ -3,9 +3,9 @@
 ## Introduction
 
 The driver uses a load balancing policy to determine which node(s) and shard(s)
-to contact when executing a query. Load balancing policies implement the
+to contact when executing a statement. Load balancing policies implement the
 `LoadBalancingPolicy` trait, which contains methods to generate a load
-balancing plan based on the query information and the state of the cluster.
+balancing plan based on the statement information and the state of the cluster.
 
 Load balancing policies do not influence to which nodes connections are
 being opened. For a node connection blacklist configuration refer to
@@ -16,9 +16,9 @@ In this chapter, "target" will refer to a pair `<node, optional shard>`.
 
 ## Plan
 
-When a query is prepared to be sent to the database, the load balancing policy
+When a statement is prepared to be sent to the database, the load balancing policy
 constructs a load balancing plan. This plan is essentially a list of targets to
-which the driver will try to send the query. The first elements of the plan are
+which the driver will try to send the statement. The first elements of the plan are
 the targets which are the best to contact (e.g. they might be replicas for the
 requested data or have the best latency).
 
@@ -73,28 +73,28 @@ let session: Session = SessionBuilder::new()
 
 In addition to being able to configure load balancing policies through
 execution profiles at the session level, the driver also allow for setting
-execution profile handles on a per-query basis. This means that for each query,
+execution profile handles on a per-statement basis. This means that for each statement,
 a specific execution profile can be selected with a customized load balancing
 settings.
 
 ## `LoadBalancingPolicy` trait
 
 ### `pick` and `fallback`:
 
-Most queries are sent successfully on the first try. In such cases, only the
+Most statements are executed successfully on the first try. In such cases, only the
 first element of the load balancing plan is needed, so it's usually unnecessary
 to compute entire load balancing plan. To optimize this common case, the
 `LoadBalancingPolicy` trait provides two methods: `pick` and `fallback`.
 
-`pick` returns the first target to contact for a given query, which is usually
+`pick` returns the first target to contact for a given statement, which is usually
 the best based on a particular load balancing policy.
 
 `fallback`, returns an iterator that provides the rest of the targets in the
 load balancing plan. `fallback` is called when using the initial picked
 target fails (or when executing speculatively) or when `pick` returned `None`.
 
 It's possible for the `fallback` method to include the same target that was
-returned by the `pick` method. In such cases, the query execution layer filters
+returned by the `pick` method. In such cases, the statement execution layer filters
 out the picked target from the iterator returned by `fallback`.
 
 ### `on_query_success` and `on_query_failure`:
@@ -103,13 +103,13 @@ The `on_query_success` and `on_query_failure` methods are useful for load
 balancing policies because they provide feedback on the performance and health
 of the nodes in the cluster.
 
-When a query is successfully executed, the `on_query_success` method is called
+When a statement is successfully executed, the `on_query_success` method is called
 and can be used by the load balancing policy to update its internal state. For
 example, a policy might use the latency of the successful query to update its
 latency statistics for each node in the cluster. This information can be used
 to make decisions about which nodes to contact in the future.
 
-On the other hand, when a query fails to execute, the `on_query_failure` method
+On the other hand, when a statement fails to execute, the `on_query_failure` method
 is called and provides information about the failure. The error message
 returned by Cassandra can help determine the cause of the failure, such as a
 node being down or overloaded. The load balancing policy can use this

docs/source/logging/logging.md

@@ -33,7 +33,7 @@ async fn main() -> Result<(), Box<dyn Error>> {
         )
         .await?;
 
-    // This query should generate a warning message
+    // This statement should generate a warning message
     session.query("USE ks", &[]).await?;
 
     Ok(())

docs/source/metrics/metrics.md

@@ -5,11 +5,11 @@ During operation the driver collects various metrics.
 They can be accessed at any moment using `Session::get_metrics()`
 
 ### Collected metrics:
-* Query latencies
-* Total number of nonpaged queries
-* Number of errors during nonpaged queries
-* Total number of paged queries
-* Number of errors during paged queries
+* Statement execution latencies
+* Total number of nonpaged statements
+* Number of errors during nonpaged statements' execution
+* Total number of paged statements
+* Number of errors during paged statements' execution
 * Number of retries
 
 ### Example