Skip to content

New api for reading xlsb#920

Merged
pjfanning merged 11 commits intoapache:trunkfrom
AdRiley:new-api-for-reading-xlsb
Oct 21, 2025
Merged

New api for reading xlsb#920
pjfanning merged 11 commits intoapache:trunkfrom
AdRiley:new-api-for-reading-xlsb

Conversation

@AdRiley
Copy link
Contributor

@AdRiley AdRiley commented Oct 17, 2025

This PR introduces a new API for reading data from xlsb files with their native types as opposed to the current methodology which returns everything as a formatted string.

This is done via the introduction of a new callback handler XSSFBSheetContentsHandler which has typed callbacks.

This change is backwards compatible with the existing API which is still present and works as it did before.

This PR also adds support for reading the error codes from the xlsb file and returning the actual error.

@AdRiley AdRiley marked this pull request as ready for review October 17, 2025 15:21
@AdRiley AdRiley requested a review from pjfanning October 17, 2025 15:52
@pjfanning
Copy link
Member

The CI run had a test failure. I'm travelling and bandwidth is too low to read the full log.

@AdRiley
Copy link
Contributor Author

AdRiley commented Oct 17, 2025

I broke this test

Test test66682() FAILED

org.opentest4j.AssertionFailedError: expected: <ERROR> but was: <#DIV/0!>

As I am now returning the actual error rather than just the generic ERROR.

Options are

  1. Make this a breaking change and fix the test
  2. Make it so the existing API continues to return ERROR for cells with errors

I can't decide which is the better option? Either is easy to do.

@pjfanning
Copy link
Member

I prefer to not break any tests. You can add a method or param that flips the behaviour but users should opt into the breaking change.

This is from real world pain with changes leading to complaints from users who rely on the behaviour as is and don't expect it to change.

@AdRiley
Copy link
Contributor Author

AdRiley commented Oct 17, 2025

OK I updated the code so the error behaviour works as it did before for the old string based API. Anyone who needs the actual error codes can use the new API.

XSSFBSheetHandler.XSSFBSheetContentsHandler handler = mockSheetContentsHandler();
testXSSFBSheetContentsHandler("testVarious.xlsb", handler);

InOrder ordered = inOrder(handler);
Copy link
Member

Choose a reason for hiding this comment

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

Why do we need mockito? Can't this be tested with the APIs as is?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because I need to test that certain callbacks get called on the XSSFBSheetContentsHandler. So I needed to either create a mock handler by hand (which is what the existing tests did) or use a third party mocking framework like mockito (that I think was already been used in other places in the code base).

@AdRiley AdRiley requested a review from pjfanning October 21, 2025 12:59
Copy link
Member

@pjfanning pjfanning left a comment

Choose a reason for hiding this comment

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

lgtm - merged

@pjfanning pjfanning merged commit 63c0bf9 into apache:trunk Oct 21, 2025
1 check passed
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