iffyio commented on code in PR #1831:
URL:
https://github.com/apache/datafusion-sqlparser-rs/pull/1831#discussion_r2067910538
##########
src/test_utils.rs:
##########
@@ -166,6 +168,30 @@ impl TestedDialects {
only_statement
}
+ /// The same as [`one_statement_parses_to`] but it works for a multiple
statements
+ pub fn statements_parse_to(
+ &self,
+ sql: &str,
+ statement_count: usize,
+ canonical: &str,
+ ) -> Vec<Statement> {
+ let statements = self.parse_sql_statements(sql).expect(sql);
+ assert_eq!(statements.len(), statement_count);
Review Comment:
Ah so I meant that in both cases when asserting :
in this case we're already explicitly check that both statements lists are
identical
```rust
assert_eq!(self.parse_sql_statements(canonical).unwrap(), statements);
```
Then in this case, we're doing so implicitly, reconstructing the input sql
based off the returned statement
```rust
assert_eq!(
sql,
statements
.iter()
.map(|s| s.to_string())
.collect::<Vec<_>>()
.join("; ")
);
```
So that i imagine it shouldn't be possible for the count assertion to fail
and either of the subsequent assertion to pass?
`one_statement_parse_to` uses the count internally and there it makes sense
to sanity check that since the expected count is always one, in this case we're
exposing the count as a function argument which makes for suboptimal API that
the user has to manually increment/decrement a counter when the sql changes. So
that if the count argument isn't strictly necessary we would want to skip it
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org
For additional commands, e-mail: github-h...@datafusion.apache.org
