Skip to content

Conversation

@adriangb
Copy link
Contributor

@adriangb adriangb commented Jan 9, 2026

I've now seen this pattern a couple of times, in our own codebase, working on apache/datafusion-comet#3047.

I was going to add an example but I think adding an API to handle it for users is a better experience.

This should also make it a bit easier to migrate from SchemaAdapter. In fact, I think it's possible to implement a SchemaAdapter using this as the foundation + some shim code. This won't be available in DF 51 to ease migration but it's easy enough to backport (just copy the code in this PR) for users that would find that helpful.

@adriangb adriangb requested a review from alamb January 9, 2026 17:03
@alamb
Copy link
Contributor

alamb commented Jan 9, 2026

(should we undeprecate the schema adapter?)

@alamb
Copy link
Contributor

alamb commented Jan 9, 2026

we can also do a 52.1.0 release too

@adriangb
Copy link
Contributor Author

adriangb commented Jan 9, 2026

I actually considered that and decided against it for a couple of reasons:

  1. There are extra methods on there that we won't be implementing, e.g. map_column_index. There are also API idiosyncrasies that I think are good to deprecate / replace (create_with_projected_schema and create each have their issues).
  2. We don't need a trait (or nested traits), the dynamic behavior is entirely determined by PhysicalExprAdapter. So at most I'd consider un-deprecating DefaultSchemaAdapter.
  3. We can't really un-deprecate it from ParquetSource/FileScanConfig, so at most we'd un-deprecate it as a standalone thing for other ad-hoc uses.

So given that we don't really want the trait, that we'd be deprecating half of the methods anyway and that the other half could use a refactor / breaking changes to simplify the APIs and that it wouldn't really help most of the use cases (FileScanConfig) I think it's best to make a new, simpler API.

@adriangb
Copy link
Contributor Author

adriangb commented Jan 9, 2026

we can also do a 52.1.0 release too

I see no reason why this can't be included in a 52.1.0 release :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants