Dennis40816 commented on issue #8250:
URL: 
https://github.com/apache/arrow-datafusion/issues/8250#issuecomment-1849890320

   @alamb After a brief review of the code in PR #7934, I would like to confirm 
my understanding and seek clarification if I have any misconceptions about the 
program structure or Rust.
   
   From my perspective, this issue should address two main tasks:
   
   1. Explicitly mark tests and related references that depend on `parquet` 
with the `#[cfg(feature = "parquet")]` attribute. This ensures that when these 
tests are run, `parquet` is automatically added to the features. For example:
   
       ```rust
       // in "datafusion/common/src/file_options/mod.rs"
       #[cfg(test)]
       mod tests {
           use std::collections::HashMap;
           
           // should add cfg flag here         <--------------
           #[cfg(feature = "parquet")]        
           use parquet::{
               basic::{Compression, Encoding, ZstdLevel},
               file::properties::{EnabledStatistics, WriterVersion},
               schema::types::ColumnPath,
           };
           // ...
   
           #[test]
           // also add cfg flag here           <--------------
           #[cfg(feature = "parquet")]
           fn test_writeroptions_parquet_from_statement_options() -> Result<()> 
{
               let mut option_map: HashMap<String, String> = HashMap::new();
               // ...
           }
           // ...
       }
       ```
   
   2. Following #7934, we should also implement a stub to trigger runtime 
errors when users forget to add `#[cfg(feature = "parquet")]` to their test 
cases, rather than encountering compile-time errors.
       ```rust
       // in "datafusion/common/src/file_options/mod.rs"
       #[test]
       fn test_writeroptions_parquet_column_specific() -> Result<()> {
         // ...
     
         // implemented in #7934
         let parquet_options = ParquetWriterOptions::try_from((&config, 
&options))?;
         // should we also implement `writer_options` for 
`ParquetWriterOptions` in the stub?
         let properties = parquet_options.writer_options();
     
         // ...
       }
       ```
   
   However, regarding the second point, I am uncertain about its feasibility. 
The concern arises if users employ new `parquet` features, which would 
necessitate corresponding updates to the stub. Would extensive use of `parquet` 
features potentially make the stub challenging to maintain?
   
   As a Rust beginner, I hope you won't mind if I ask a seemingly naive 
question.


-- 
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]

Reply via email to