dannycjones commented on issue #3258:
URL: https://github.com/apache/iceberg-rust/issues/3258#issuecomment-5778475419
> Re-reading, I want to check to make sure I understand the intent here: is
the idea to have a central capability check for whether a type is safe to
read/write, and then enforce that at the relevant entry points (scan planning,
writers, etc.)?
>
> If so, I wonder if read/write alone is enough granularity. For example, a
type might support decoding/encoding values correctly but not yet support
metrics, predicates, or bounds. Geometry seems like an example where writing
the value is safe as long as unsupported bounds are omitted.
>
> Would it make sense to model this as capabilities (read, write, metrics,
etc.) and have the relevant paths check the capability they require?
Yeah, a capabilities model is a good way to describe it (and also Matt
suggested similar). My prototyping actually includes a
`Type::supports_bounds(&self) ->
BoundsSupport::{Supported,NotYetImplemented,Unsupported}` check which omits on
`NotYetImplemented` and rejects `Unsupported` (for container types, which the
library should never try to calculate bounds for).
I'm open to ideas. I wanted to start the conversation here, and felt that a
coarse read/write can provide an initial gate and start to document somewhere
centrally what needs to be implemented.
When I get a prototype in shape, I'll share a draft PR so we can start
discussing over something more tangible if that helps. I also had in mind a
`supports_equality_deletes` capability too, which forbids `float` and `decimal`
(and maybe geo, that one is still ambiguous for me).
--
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]
