feat: add support for column index limit in ReadSheet#942
Conversation
|
Welcome to participate in open source contributions. Please refer to the contribution guide, complete your PR content and modify the commit message format, and provide the unit test code. |
|
Please refer to the code contribution. Make sure the changes can be compiled and are properly formatted :) |
No I cannot make sure it compiles on CI, maybe locally but not on CI |
To prevent CI from being blocked by formatting or compilation issues, you can first run Please refer to the code contribution. |
Hi, may I ask if this is a draft PR? I haven't seen any complete implementation logic for this new parameter, and there are no use cases of reading Excel files in the unit test code either. |
not a draft PR, i will extend it to add a complete implementation logic for the new parameter, as well as a test based on reading dummy data. But also it depends what do you mean by "complete implementation logic"? |
It's okay. Please continue to develop and refine this PR, and conduct unit tests in the local environment. When a PR is ready for code review by community members, you can leave a message to let us know. |
|
@delei @bengbengbalabalabeng my understanding is that fesod does not support reading a sheet by column (only by rows) but it can write to a square set of cells, is that correct? where this logic of the this PR should also be propagated? which classes are also concerned with reading with a column index? |
Reading and converting the data in cells is achieved through the BTW, I'm a little worried about this PR. Could you please start the preliminary discussion in the issue and provide your proposed solution? (e.g. #941 ) I didn't mean any offense, the other members of the community generally do not discuss proposals in the PR. This would help save the time for the code review. |
@delei I meant not "in n cells" but in rows AND columns. And not a listnener function. That was a severe limitation of fesod thankfully this PR comes to the rescue, the idea is clear and simple (read a sheet by rows and columns) i think there is no need to describe it more |
|
@delei can you review the pr? |
Please fix the errors identified in the CI and ensure that the CI can pass successfully. |
| Assertions.assertNotNull(readResults); | ||
| Map<Integer, String> parsedRow = readResults.get(0); | ||
| Assertions.assertEquals("1", parsedRow.get(0)); | ||
| Assertions.assertEquals("Alice", parsedRow.get(1)); |
There was a problem hiding this comment.
List<Integer> targetColumns = Arrays.asList(0, 2);The targetColumns variable has been set to only include columns 0 and 2, why are there three columns of data in the result?
Is there any misunderstanding or unfinished code logic?
There was a problem hiding this comment.
I will correct, i wrongly thought that it is from to
There was a problem hiding this comment.
I would like to know what features you have implemented through this PR.
Is it the case that the readResults variable only contains data from these two columns?
Assertions.assertEquals(2,parsedRow.size());There was a problem hiding this comment.
Yes thats correct
There was a problem hiding this comment.
Can we continue to develop it so that it can support xls files at the same time?
There was a problem hiding this comment.
@delei I will do that in a separate PR, pls merge this xlsx work first
There was a problem hiding this comment.
Thank you for your willingness to continue contributing to open source.
IMO, due to the introduction of new parameters, I hope this is a complete PR that includes all the features, making it easier for community members to understand this parameter.
You can also continue to submit new PR to add documentation for this parameter, optimize the code, or fix minor errors.
There was a problem hiding this comment.
@delei sure I will add docs as well for this (in a separate PR), thanks
delei
left a comment
There was a problem hiding this comment.
LGTM.
BTW, currently, only xlsx files are supported.
@delei yes |
de14e8d to
e6869c3
Compare
b51a253 to
fa2c984
Compare
|
@bengbengbalabalabeng all your reviews have been addressed by now |
|
|
||
| tempCellData.checkEmpty(); | ||
| tempCellData.setRowIndex(xlsxReadSheetHolder.getRowIndex()); | ||
| tempCellData.setColumnIndex(xlsxReadSheetHolder.getColumnIndex()); |
There was a problem hiding this comment.
Considering the earlier logic, assigning tempCellData.setColumnIndex(targetColumnIndex) here might make the behavior more consistent. What do you think :)
There was a problem hiding this comment.
targetColumnIndex is assigned in an if clause, so it would not make sense to assign here for all cases.
There was a problem hiding this comment.
Considering the earlier logic, assigning
tempCellData.setColumnIndex(targetColumnIndex)here might make the behavior more consistent.
Sorry for the confusion, my previous comment might not have been clear enough. Here is what I actually meant:
// ...
if (includeColumnIndexes == null) {
targetColumnIndex = xlsxReadSheetHolder.getColumnIndex();
} else {
// If it's a target column, rewrite the cell's internal index and pack it sequentially
targetColumnIndex = includeColumnIndexes.indexOf(xlsxReadSheetHolder.getColumnIndex());
if (targetColumnIndex < 0) {
return;
}
}
// ...
// line: 136 (old 154)
tempCellData.setColumnIndex(targetColumnIndex);Since we guarantee targetColumnIndex is resolved in both branches, placing setColumnIndex() outside the block maintains the exact same logic while avoiding code duplication. What do you think :)
There was a problem hiding this comment.
Yes, that is correct and more readable.
There was a problem hiding this comment.
@bengbengbalabalabeng the refactoring has been implemented now, you can merge this PR as well as this related passing test: #945
There was a problem hiding this comment.
In the previous version, when includeColumnIndexes != null, the assignment of tempCellData.setColumnIndex() was the overridden targetColumnIndex. Now, however, tempCellData.setColumnIndex() always uses the original xlsxReadSheetHolder.getColumnIndex() instead.
I want to confirm whether this change is intentional. Would you mind clarifying the expected behavior here?
There was a problem hiding this comment.
I must have overlooked this, now it is changed as it was in the previous correct version.
93ec8a2 to
cbd1291
Compare
f4583f1 to
6379674
Compare
|
Hi @sapienza88, Please help confirm whether the updated PR description accurately reflects the changes. |
@bengbengbalabalabeng it absolutely does, thank you for adding it |
bengbengbalabalabeng
left a comment
There was a problem hiding this comment.
LGTM.
Merge in 24h.
Purpose of the pull request
Related: #950
What's changed?
Column filtering behavior:
CellTagHandler#endElementWhen
includeColumnIndexes != null:When
includeColumnIndexes == null:API Usage Example
Checklist