liurenjie1024 commented on issue #1314:
URL: https://github.com/apache/iceberg-rust/issues/1314#issuecomment-2900075321
> > For example, it requires copy/list as required methods, which are not
required by FileIO(this interface is optional).
>
> You can and people do leave methods unimplemented.
That's the problem, we are defining a richer interface that's not used by
iceberg, then it would be confusing for people who want to define their own
`FileIO` implementation, which part should they implement, and which part they
should not? Also confusing for user, they are supposed to be careful when using
`FileIO` since some implementation may not implement some methods.
Also another concern is that, if we delegate a core abstraction like
`FileIO` to `object_store`, we may experience unnecessary breaking changes
introduces when `object_store` evolves.
About the design part, I'm thinking about following design considerations:
1. We should define small trait rather than a large trait. For example we
could define traits like following `FileIO`, `SupportsBulkOperations` , etc. So
that concrete implementations could choose which traits to implement according
their capability.
2. We could have an erased trait object definition for traits defined in 1,
say `DynFileIO`, which are object safe.
3. For end user, we could provide a struct to wrap the `DynFileIO` trait
object.
(We could discuss naming of each part)
Here is an example:
```rust
trait InputFile {
...
}
trait FileIO {
type I: InputFile;
}
trait DynFileIO {
}
struct FileIOWrapper {
inner: Arc<dyn DynFileIO>
}
```
--
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: issues-unsubscr...@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
