feat: add support for column-based reading of XLS files

[sapienza88]

Related #942

Summary: Column-based filtering support for XLS.

What's changed?
Added support for column-based reading for XLS

[nkuprins]

I am not a maintainer, but it might be worth checking contribution guide, as the commit messages and PR don't seem to follow the format :)

[sapienza88]

I am not a maintainer, but it might be worth checking contribution guide, as the commit messages and PR don't seem to follow the format :)

Unless you have a genuine reason related to the review of this PR, I don't feel obliged to respond to your inquiry. It is indeed up to the maintainers of this project to ask me this and only then I can proceed to the modifications.

[delei]

We are grateful to all the volunteers.

All contributors and committers can voluntarily participate in the code review process, have friendly exchanges, and offer their own suggestions.

Although the contribution guidelines are not binding or mandatory, following them can help community members understand the content of PR, which can effectively save time.

[sapienza88]

We are grateful to all the volunteers.

All contributors and comitters can voluntarily participate in the code review process, have friendly exchanges, and offer their own suggestions.

Although the contribution guidelines are not binding or mandatory, following them can help community members understand the content of PR, which can effectively save time.

@delei if anyone has an inquiry about this PR to "understand the content of PR", they can ask directly, but to ask to follow any guideline it is not their responsability as far as I know (+ this PR is a follow-up one to a previous related well-documented merged PR: which makes this PR relatively easier to understand).

[nkuprins]

We are grateful to all the volunteers.
All contributors and comitters can voluntarily participate in the code review process, have friendly exchanges, and offer their own suggestions.
Although the contribution guidelines are not binding or mandatory, following them can help community members understand the content of PR, which can effectively save time.

@delei if anyone has an inquiry about this PR to "understand the content of PR", they can ask directly, but to ask to follow any guideline it is not their responsability as far as I know.

I don't want to spam the thread, but FYI, I was looking at the PR content (not just commit messages). I do this because I have a genuine interest in the project. Besides, Apache is about community, so I obviously have a genuine interest in the code of other people and not just my own.

Regarding formatting guidelines. It was meant to be a kind remark that I noticed and verified. Commit messages and PR template are important to help to understand the code for other people. I did not require you to do anything, as I said "might be worth checking". After that, I wanted to ask the question about the content, but that takes time to verify to be 100% sure.

For your convenience, I will refrain from any remarks specifically about your code or formatting in the future.

Let's end on this and not spam the thread, please :)

[sapienza88]

@bengbengbalabalabeng can you merge this if all is ok?

[bengbengbalabalabeng]

Please also add the following cell record types in sync: LabelRecordHandler, FormulaRecordHandler, RKRecordHandler, BoolErrRecordHandler, BlankRecordHandler, DummyRecordHandler -> MissingCellDummyRecord, to ensure read consistency of XLS under column-based filtering.

[sapienza88]

Please also add the following cell record types in sync: LabelRecordHandler, FormulaRecordHandler, RKRecordHandler, BoolErrRecordHandler, BlankRecordHandler, DummyRecordHandler -> MissingCellDummyRecord, to ensure read consistency of XLS under column-based filtering.

Yes I was planning that in a seperate PR

[bengbengbalabalabeng]

Yes I was planning that in a seperate PR

No need to split off a new PR, just keep refining it in the current one, which also makes the overall review easier.

[sapienza88]

Yes I was planning that in a seperate PR

No need to split off a new PR, just keep refining it in the current one, which also makes the overall review easier.

@bengbengbalabalabeng OK

[delei]

If the timeline is uncertain, you can leave a comment in the existing issue #950 outlining your plans or the remaining tasks, and we can assign the task to you.

If it is not completed by the release milestone, we will allow other volunteers to continue contributing and refining it.

[sapienza88]

@bengbengbalabalabeng pls check the progress through the latest commit. @delei

[bengbengbalabalabeng]

In the previous XLSX format implementation, extended record types such as Note were not included in the column filtering logic.

The current PR mainly focuses on column index mapping for regular cell records to ensure consistency in the core reading flow.

NOTE (NoteRecordHandler) is an extended optional record type that typically does not participate in the main dataset processing flow. Therefore, whether additional handling of the NOTE (NoteRecordHandler) type is needed this time, you may want to confirm the requirement scope.

[sapienza88]

The current PR mainly focuses on column index mapping for regular cell records to ensure consistency in the core reading flow.

NOTE (NoteRecordHandler) is an extended optional record type that typically does not participate in the main dataset processing flow. Therefore, whether additional handling of the NOTE (NoteRecordHandler) type is needed this time, you may want to confirm the requirement scope.

that's correct, NOTE metadata is not needed in the context of this PR