Skip to content
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

Fix Arrow deserialization for FlatArray #29

Merged
merged 1 commit into from
Nov 20, 2023
Merged

Fix Arrow deserialization for FlatArray #29

merged 1 commit into from
Nov 20, 2023

Conversation

ararslan
Copy link
Member

Tests currently fail with the latest compatible versions of this package's dependencies because deserializing a FlatArray from Arrow ends up calling a FlatArray constructor method that doesn't exist: FlatArray(vec, size). What it should actually call is the inner constructor, FlatArray{T}(vec, size). To fix this, we can define a method for fromarrow from ArrowTypes to simply call the inner constructor. An analogous change is not needed for Weights because the method that fromarrow calls by default does exist in that case.

Note that no new tests were added. This is because the current tests actually cover this case.

Originally encountered by then pair debugged with @patinoam.

Tests currently fail with the latest compatible versions of this
package's dependencies because deserializing a `FlatArray` from Arrow
ends up calling a `FlatArray` constructor method that doesn't exist:
`FlatArray(vec, size)`. What it should actually call is the inner
constructor, `FlatArray{T}(vec, size)`. To fix this, we can define a
method for `fromarrow` from ArrowTypes to simply call the inner
constructor. An analogous change is not needed for `Weights` because the
method that `fromarrow` calls by default does exist in that case.

Note that no new tests were added. This is because the current tests
actually cover this case.

Co-Authored-By: Angelica Patino <[email protected]>
Copy link

codecov bot commented Nov 20, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (27acd1b) 94.11% compared to head (25ca360) 94.33%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #29      +/-   ##
==========================================
+ Coverage   94.11%   94.33%   +0.22%     
==========================================
  Files           2        2              
  Lines          51       53       +2     
==========================================
+ Hits           48       50       +2     
  Misses          3        3              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@kleinschmidt kleinschmidt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pretty irritating that somehow an in-practice-breaking change snuck in for a non-breaking-version bump of a dependency. any idea which that might be? otherwise looks good to me, thanks for the fix!

@ararslan
Copy link
Member Author

any idea which that might be?

Based on the error, my only guess would be ArrowTypes, which this package uses like a submodule of Arrow rather than as a distinct dependency. That means we effectively inherit Arrow's compat bound on ArrowTypes.

@ararslan ararslan merged commit 5e26df4 into main Nov 20, 2023
6 checks passed
@ararslan ararslan deleted the aa/fromarrow branch November 20, 2023 23:45
@ericphanson
Copy link
Member

I believe it was Arrow 2.6. A lot of our internal packages that use LegolasFlux compat bounded to 2.5 to avoid this and other similar issues (but I guess we did not file an issue here or anything 😅).

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.

3 participants