fqaiser94 opened a new issue, #488:
URL: https://github.com/apache/iceberg-rust/issues/488

   There was an unresolved 
[discussion](https://github.com/apache/iceberg-rust/pull/475#discussion_r1690861564)
 about whether we should: 
   - Allow users to configure a path as a root of the catalog and create tables 
underneath that or
     - Pros:
       - Aligns with the approach generally taken on the Java side 
([defaultWarehouseLocation](https://github.com/apache/iceberg/blob/4dbc7f578eee7ceb9def35ebfa1a4cc236fb598f/core/src/main/java/org/apache/iceberg/BaseMetastoreCatalog.java#L195))
     - Cons:
       - Adds another parameter for initializing `MemoryCatalog`
   - Users should configure `FileIO` with a `root` path (this is the approach 
currently implemented in iceberg-rust code)
     - Pros:
       - Consolidates path-related concerns in `FileIO`
     - Cons:
       - I think users may have to be aware of this implementation detail 
because when they send a CreateTableRequest, the location should not provide an 
absolute path, but rather a relative path from the assumed root location. I'll 
also add that Iceberg community has so far not been super receptive to the idea 
of relative paths. 
       - None of the Java `FileIO` implementations I looked at (`S3FileIO`, 
`GcsFileIO`) allow configuring a `root` path. I suspect this may affect 
interoperability with the Java ecosystem, not 100% sure though. 
   
   Both are completely feasible from a technical perspective. The concern is 
more to do with API design. 
   
   Overall, I have concerns about option 2 (which is what is currently 
implemented) and am currently in favour of changing the code to follow option 
1: allow users to configure a path as a root of the catalog and create tables 
underneath that. 
   
   Thoughts? 


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


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to