alamb opened a new pull request, #2239:
URL: https://github.com/apache/arrow-rs/pull/2239

   # Which issue does this PR close?
   
   Closes https://github.com/apache/arrow-rs/issues/1091
   
   (I will file a follow on ticket to make the metadata type handling uniform 
between `Schema` and `Field`)
   
   # Rationale for this change
    
   Whenever working with `Schema` (e.g. project, etc) I often find myself 
having to `clone()` `fields` and `metadat` which is:
   1. Inefficient (often we are copying when we already have an owned Schema)
   2. Akward (and easy to forget to copy metadata)
   
   This most recently happened to me on this PR like 
https://github.com/apache/arrow-datafusion/pull/2985
   
   @jorgecarleitao  and I discussed various options on 
https://github.com/apache/arrow-rs/issues/1091 and he suggested that that 
making members of `Schema` `pub` would be good as he astutely observed that
   
   > there is no invariant betweem them [members of Schema] , so there is 
nothing that users can break by accessing individual members.
   
   # What changes are included in this PR?
   1. Make `Schema` fields pub
   2. Add a test outside the crate to use that
   
   # Are there any user-facing changes?
   Fields are pub 🎉 
   
   # Alternates considered
   I also considered making a function like the following to allow 
destructuring the `Schema`
   
   ```rust
   impl Schema {
     // Consume self and return the consitutuent parts
     pub fn into_parts(self) -> (Vec<Field>, HashMap<String, String>)) {
       (self.fields, self.metadata
     }
   }
   ```
   
   And this would satisfy my usecase and I am happy to do this instead if 
reviewers prefer. 
   
   After I reread  https://github.com/apache/arrow-rs/issues/1091 I decided I 
would propose the 'make things pub' first and see what I reaction I got. 
   
   cc @nevi-me @seddonm1 @tustvold @HaoYang670 @andygrove @viirya 


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