-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: construct StructArray
w/ FieldRef
#4116
refactor: construct StructArray
w/ FieldRef
#4116
Conversation
a21a67b
to
182506c
Compare
FYI - #4064 |
I would take that one as well, I don't really care. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me. Thank you @crepererum
This PR appears to need a |
182506c
to
6dd2d27
Compare
I think #4064 just needs some tests -- shall we combine efforts? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to confess to being a bit torn, on the one hand this PR improves the existing StructArray::from
API, but on the other-hand these APIs are rather cumbersome and part of me sort of hoped to remove them. I personally think the approach in #4064 is cleaner, more easily discoverable / consistent and is also faster, but I appreciate I am not impartial here.
I'm therefore left wondering if it is better to just encourage people to use the constructor approach, instead of refining what is a somewhat unfortunate API? Appreciate other thoughts on this...
If we are going for this I recommend we deprecate the unfortunate API |
And we could always do both 🤔 |
I can also push #4064 over the finish line later this week and close this PR. :) |
`DataType` uses `Fields`/`FieldRef` internally. Accepting `Field` just to wrap it into an `Arc` is unnecessary expensive, esp. when the `Field` was cloned from an `FieldRef` (happens in some non-test code). I've decided to NOT allow the construction from `Field` anymore because in prod code this is most likely a performance bug.
6dd2d27
to
fa3d4f8
Compare
I think this is still worth merging (or we delete the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My vote would be for removing them, but I guess this is also fine, it is a shame there is no way to deprecate a trait implementation
How about we propose removing them in a follow on PR |
Which issue does this PR close?
-
Rationale for this change
DataType
usesFields
/FieldRef
internally. AcceptingField
just to wrap it into anArc
is unnecessary expensive, esp. when theField
was cloned from anFieldRef
(happens in some non-test code).I've decided to NOT allow the construction from
Field
anymore because in prod code this is most likely a performance bug.What changes are included in this PR?
Change
From
impls forStructArray
to useFieldRef
instead ofField
.Are there any user-facing changes?
Breaking: Constructor changes.