alamb commented on PR #6726: URL: https://github.com/apache/arrow-rs/pull/6726#issuecomment-2473316362
> I'm not sure about this, casting by name comes with its own sets of issues, from performance to potential ambiguity. I agree it is non obvious and this the user should have to explicitly request this behavior > > I wonder if this is really the right level to be implementing this logic, or whether this really belongs in some sort of higher-level schema adapter. I personally think it makes sense in the cast kernel as it is a common operation (e.g. to convert structs with the same fields but in different order) However that being said, a `Struct` is basically like a `Schema` (named fields with types) so I can see the argument that by supporting this type of cast in arrow-rs it will evolve over time into a schema adapter / matching code (e.g. filling out missing columns with NULLs, reordering columns, etc) > > Tagging @alamb as there is a fair amount of such schema munging logic in DF. > > Regardless this is a breaking API change as written I agree. I also think it would be nice to avoid a breaking change if not necessary and I don't think it is necessary in this case. Tto make it not a breaking change I think we could introduce `can_cast_types_with_options` to mirror [`cast_with_options` ](https://docs.rs/arrow/latest/arrow/compute/fn.cast_with_options.html) and then control the field level rearranging based on the fields of `CastOptions` -- 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]
