alamb commented on code in PR #6469:
URL: https://github.com/apache/arrow-datafusion/pull/6469#discussion_r1210334068
##########
datafusion/core/src/datasource/listing/table.rs:
##########
@@ -418,7 +421,7 @@ impl ListingOptions {
///
/// assert_eq!(listing_options.file_sort_order, file_sort_order);
/// ```
- pub fn with_file_sort_order(mut self, file_sort_order: Option<Vec<Expr>>)
-> Self {
+ pub fn with_file_sort_order(mut self, file_sort_order: Vec<Vec<Expr>>) ->
Self {
Review Comment:
🤔 i wonder if this API would be simpler to use if it was something like
```
/// add a new equivalent sort order
pub fn with_file_sort_order(mut self, file_sort_order: Vec<Expr>) ->
Self {
self.file_sort_order.push(file_sort_order);
self
}
```
I realize that would be different too 🤔
I am just thinking in general `Vec<Vec<...>>` makes for a harder to
understand API because the type names don't help you and you have to figure out
that the inner Vec represents.
##########
datafusion/sql/src/parser.rs:
##########
@@ -585,7 +588,7 @@ impl<'a> DFParser<'a> {
delimiter: Option<char>,
file_compression_type: Option<CompressionTypeVariant>,
table_partition_cols: Option<Vec<String>>,
- order_exprs: Option<Vec<OrderByExpr>>,
+ order_exprs: Vec<Vec<OrderByExpr>>,
Review Comment:
🤔 I wonder why some changes in this PR use the newly introduced
`LexOrdering` and some places use `Vec<OrderByExpr>` ? It would probably make
the code easier to follow if one convention was used throughout
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
