Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add integration tests for query parameters #1235

Open
wants to merge 8 commits into
base: branch-hackathon
Choose a base branch
from

Conversation

sylwiaszunejko
Copy link
Contributor

Moved some tests from different files and added new ones inspired by java-driver tests.

Pre-review checklist

  • I have split my patch into logically separate commits.
  • All commit messages clearly explain what they change and why.
  • I added relevant tests for new features and bug fixes.
  • All commits compile, pass static checks and pass test.
  • PR description sums up the changes and reasons why they should be introduced.
  • I have provided docstrings for the public items that I want to introduce.
  • I have adjusted the documentation in ./docs/source/.
  • I added appropriate Fixes: annotations to PR description.

Copy link

github-actions bot commented Feb 12, 2025

cargo semver-checks found no API-breaking changes in this PR! 🎉🥳
Checked commit: 8c41770

Copy link
Contributor

@muzarski muzarski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I'm thinking if query.rs is a good name for the module (we are trying to rename the Query struct before the 1.0.0 - most probably it will be renamed to Statement). I think it should be maybe called statement.rs? These tests indeed verify correctness binding values to the statement, and some statement config parameters (e.g. timestamps)

Comment on lines 53 to 80
regular_query.set_timestamp(Some(420));
session
.query_iter(
regular_query.clone(),
("regular query iter", "higher timestamp"),
)
.await
.unwrap();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm actually shocked that it works. The usual use case for [query/execute]_iter is to use them with SELECT statements (here we use INSERT). I was almost sure that we throw an error in case response is not RESULT:Rows. But then I saw this in pager.rs:

            Ok(NonErrorQueryResponse {
                response: NonErrorResponse::Result(_),
                tracing_id,
                ..
            }) => {
                // We have most probably sent a modification statement (e.g. INSERT or UPDATE),
                // so let's return an empty iterator as suggested in #631.

                // We must attempt to send something because the iterator expects it.
                let (proof, _) = self.sender.send_empty_page(tracing_id).await;
                Ok(ControlFlow::Break(proof))
            }

In such case, it's nice you extended the test cases by query/execute_iter scenarios.

Comment on lines 444 to 445
async fn test_deserialize_empty_collections() {
// Setup session.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this test does not belong here. It should be placed in deserialization test suite (the closest one is integration/cql_types.rs I believe) cc: @Lorak-mmk

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't yet read this PR nor #1232 , but please make sure that you are not repeating the same work

Comment on lines 563 to 590
let result = session
.query_single_page(query.clone(), (KEY, 1), PagingState::start())
.await;
assert_matches!(
result,
Err(ExecutionError::LastAttemptError(
RequestAttemptError::SerializationError(_)
))
);

let prepared_query = session.prepare(query).await.unwrap();

let result = session.execute_unpaged(&prepared_query, (KEY, 1)).await;
assert_matches!(
result,
Err(ExecutionError::BadQuery(BadQuery::SerializationError(_)))
);

let result = session.execute_iter(prepared_query.clone(), (KEY, 1)).await;
assert_matches!(result, Err(PagerExecutionError::SerializationError(_)));

let result = session
.execute_single_page(&prepared_query, (KEY, 1), PagingState::start())
.await;
assert_matches!(
result,
Err(ExecutionError::BadQuery(BadQuery::SerializationError(_)))
);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm glad we have some test cases which kinda show the difference between ExecutionError::BadQuery::SerializationError and ExecutionError::LastAttemptError::SerializationError. I know that it must be confusing that SerializationError appears twice in errors hierarchy. This is something we will be trying to fix in the future. But the fix for this is non-trivial, and we won't be able to do that before 1.0.0,

@sylwiaszunejko
Copy link
Contributor Author

I changed the file name as suggested, moved test_deserialize_empty_collections and made error matches more specific.

Comment on lines 10 to 24
#[tokio::test]
async fn test_prepared_config() {
setup_tracing();
let session = create_new_session_builder().build().await.unwrap();

let mut query = Query::new("SELECT * FROM system_schema.tables");
query.set_is_idempotent(true);
query.set_page_size(42);

let prepared_statement = session.prepare(query).await.unwrap();

assert!(prepared_statement.get_is_idempotent());
assert_eq!(prepared_statement.get_page_size(), 42);
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apart from idempotency and page_size, could you also check:

  • consistency
  • serial consistency
  • tracing
  • request_timeout
    And other parameters that should survive preparation (see the metods on PreparedStatement and Query)
    ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added additional checks, is there something more I should add?

Comment on lines 27 to 70
let query_str = format!("INSERT INTO {}.t_timestamp (a, b) VALUES (?, ?)", ks);

// test regular query timestamps

let mut regular_query = Query::new(query_str.to_string());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⛏️ Needless to_string() - format! already returns a String.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to_string() is still there, but there is no format! after I started using USE ks

@sylwiaszunejko sylwiaszunejko force-pushed the hackathon_test_query branch 2 times, most recently from a6e85e7 to 5193daf Compare February 13, 2025 14:38
Copy link
Contributor

@muzarski muzarski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some commit titles still mention query.rs (which we decided to rename to statement.rs)

@sylwiaszunejko
Copy link
Contributor Author

I changed the commit message to mention correct file

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants