Extend scope of @ExcelCellName and @ExcelCell 'mandatory' flag to constrain cell values.

Question

Extend scope of @ExcelCellName and @ExcelCell 'mandatory' flag to constrain cell values.

rob-heaney-itg opened this issue 2 years ago · comments

Hi,

It would be great if the scope of the "mandatory" constraint (on the @ExcelCellName and @ExcelCell annotations) could be extended to affect the actual cell values, not just column headers. Is this possible?

Either that, or perhaps add support to PoijiOptions to allow for instantiating POJOs through our own all-arg-constructors, so that we can effectively add our own mandatory/optional validation during each row/cell creation, perhaps?

Not sure which is easier, but open to ideas if there are alternatives.
Thanks in advance.

github-actions · Answer 1 · Wed Mar 23 2022 01:51:38 GMT+0800 (China Standard Time)

Thank you for contributing to Poiji! Feel free to create a PR If you want to contribute directly :)

Rob · Answer 2 · Thu Mar 24 2022 20:01:12 GMT+0800 (China Standard Time)

Hi @ozlerhakan,

If it helps, I have created a "draft" working example of how this could be approached. However, it's by no means production code, nor with the appropriate unit test coverage, just purely a concept demonstration. So rather than muddy your project repo with branches & pull-requests, is there somewhere I can provide you with a "work-in-progress" patch file for you to review?

Thanks

Hakan Özler · Answer 3 · Fri Mar 25 2022 01:14:43 GMT+0800 (China Standard Time)

Hi @rob-heaney-itg ,

Thank you for contributing to Poiji!

I come up with two options for this case:

just fork Poiji do your changes on top of the master in a new branch and we can see how it goes on your forked repo.
just fork Poiji do your changes on top of the master in a new branch and create a patch, and send it to me. I can review and send you a reviewed patch.

What do you think?

Rob · Answer 4 · Fri Mar 25 2022 01:22:40 GMT+0800 (China Standard Time)

Hi @ozlerhakan,

That sounds great. Please see attached below.

ISSUE-233___WORKING_EXAMPLE.patch.txt

Thank you for your consideration.

Hakan Özler · Answer 5 · Fri Mar 25 2022 02:58:05 GMT+0800 (China Standard Time)

Thank you @rob-heaney-itg , I will look at it in 3 days.

Hakan Özler · Answer 6 · Sat Mar 26 2022 20:22:37 GMT+0800 (China Standard Time)

Hi @rob-heaney-itg , It looks promising your changes, these changes are for xls files only, do you want to add the same ability for xlsx files? BTW I opened up a new branch called 3.1.8. You can make your PR on this branch. Thank you again! :) we can tune a bit more once you make your changes on code.

Rob · Answer 7 · Tue Mar 29 2022 00:42:39 GMT+0800 (China Standard Time)

Hi @ozlerhakan,

I did have a look into how to do the equivalent for XLSX files with the XSSFUnmarshaller, but in all honesty, I couldn't quite see where it could be done. Correct me if I'm wrong, but all the parsing in the XSSFUnmarshaller seems to be completely delegated to whichever SAXParser implementation you have on your classpath...? So it seems difficult to configure in the same way.

Besides, I am personally parsing my files separately and extracting each Sheet first, before passing to Poiji, so I'm only ever utilising the SheetUnmarshaller, which looks to be based solely on the HSSFUnmarshaller.

Again though, I'm open to new ideas, if you can see an approach that I've missed...?

Hakan Özler · Answer 8 · Sat Apr 02 2022 02:21:58 GMT+0800 (China Standard Time)

ah I see @rob-heaney-itg , we can first go for XLS files then we can take another look at how we can do for XLSX files however, It might not be cover the same approach as XLSs.

Rob · Answer 9 · Wed Apr 06 2022 23:43:15 GMT+0800 (China Standard Time)

Hi @ozlerhakan , I don't appear to have permission to push commits to your 3.1.8 branch.

Is it best for you to commit my patch for me please?

Thanks

Hakan Özler · Answer 10 · Sat Apr 09 2022 04:03:14 GMT+0800 (China Standard Time)

you can create a PR, the base branch will be 3.1.8. so the changes will be merged to 3.1.8 not master, or I can commit your patch no problem.

Rob · Answer 11 · Sun Apr 10 2022 22:16:16 GMT+0800 (China Standard Time)

Yes please @ozlerhakan, I would appreciate if you can commit, thank you.

hoemich · Answer 12 · Mon Apr 11 2022 21:28:22 GMT+0800 (China Standard Time)

Would it be possible to differentiate between a mandatory header and a mandatory value?
We use this useful library to parse XLSX-files which are generated by some legacy systems.
We have columns with mandatory values but no header.
And @ozlerhakan could you consider - for such backward incompatible changes - to increase more than just the patch version? We were quite surprised how much code change has been necessary when increasing version from 3.1.1 to 3.1.5, when the default behavior for column headers suddenly changed.

Rob · Answer 13 · Mon Apr 11 2022 21:54:40 GMT+0800 (China Standard Time)

Would it be possible to differentiate between a mandatory header and a mandatory value?

Yes, I do agree actually, it would be much better to support separate flags in the annotation, rather than a global flag inside the PoijiOptions, as originally suggested.

Something like this perhaps:
@ExcelCellName(value = "myColumnName", mandatoryHeader = false, mandatoryCell = false)
or
@ExcelCellName(value = "myColumnName", mandatory = [HEADER|CELL|HEADER_AND_CELL|NONE])

Hakan Özler · Answer 14 · Tue Apr 12 2022 03:34:44 GMT+0800 (China Standard Time)

I see @hoemich , we might go for what @rob-heaney-itg suggests.

Rob · Answer 15 · Thu Apr 14 2022 20:03:00 GMT+0800 (China Standard Time)

Hi @ozlerhakan , do you have a target time-frame as to when you could include this in your next release?

Hakan Özler · Answer 16 · Fri Apr 15 2022 03:47:40 GMT+0800 (China Standard Time)

probably next week @rob-heaney-itg

Rob · Answer 17 · Tue May 03 2022 19:17:39 GMT+0800 (China Standard Time)

Hi @ozlerhakan , any update at all? Thanks

Hakan Özler · Answer 18 · Thu May 05 2022 02:50:05 GMT+0800 (China Standard Time)

Hi @rob-heaney-itg ,

I'm on holiday, I need to schedule for the changes

Rob · Answer 19 · Fri May 27 2022 18:54:11 GMT+0800 (China Standard Time)

Not a problem @ozlerhakan , hope you enjoyed your holiday.

Would be good to know when this gets scheduled in, if you don't mind keeping us in the loop?

Many thanks

Rob · Answer 20 · Tue Jul 12 2022 18:38:54 GMT+0800 (China Standard Time)

Hi @ozlerhakan , any update on this?

Thanks

Hakan Özler · Answer 21 · Sun Aug 14 2022 19:43:30 GMT+0800 (China Standard Time)

I want to close this issue ASAP @rob-heaney-itg , sorry

Rob · Answer 22 · Wed Aug 17 2022 20:18:10 GMT+0800 (China Standard Time)

Thanks for the update @ozlerhakan 👍 Appreciate the commitment 😃

However, I've just noticed you've updated to Java 17 now ..... I really wish this issue had been released before the Java upgrade was, because the project we're using this on is stuck on Java 11 (with no possibility to upgrade to 17 any time soon!) .... Any chance of reverting the Java17-upgrade and only merging after this issue is released? Is that possible?

Hakan Özler · Answer 23 · Thu Aug 18 2022 18:37:29 GMT+0800 (China Standard Time)

Hi @rob-heaney-itg ,

We can provide it for both v3.1.7 and the latest version.

Rob · Answer 24 · Thu Aug 18 2022 19:22:30 GMT+0800 (China Standard Time)

Hi @ozlerhakan, ok thank you, that'd be great. If that's the case, then yes I'd appreciate a Java11 version once this issue is merged/released. Many thanks again.

Rob · Answer 25 · Wed Dec 07 2022 00:15:53 GMT+0800 (China Standard Time)

Hi @ozlerhakan , is there any update on this, by any chance?

Hakan Özler · Answer 26 · Wed Dec 21 2022 20:58:59 GMT+0800 (China Standard Time)

Hi @rob-heaney-itg , I extremely get around to it at the xmas week :)

Hakan Özler · Answer 27 · Wed Dec 28 2022 20:44:33 GMT+0800 (China Standard Time)

We'll leverage Java 11 features again rather than Java 17.

Hakan Özler · Answer 28 · Thu Dec 29 2022 05:41:58 GMT+0800 (China Standard Time)

Hi @rob-heaney-itg , do you have any null cell example?

Hakan Özler · Answer 29 · Thu Dec 29 2022 18:23:42 GMT+0800 (China Standard Time)

First off, I'm sorry for being so late @rob-heaney-itg thank you for your support and priceless patience @rob-heaney-itg @hoemich 🙏 you can use 3.2.0 at the moment.

Valts Mazurs · Answer 30 · Fri Dec 30 2022 19:00:03 GMT+0800 (China Standard Time)

As this was backwards-incompatible change, perhaps it would bring additional clarity, if the project followed SemVer and bumped the major version number to 4 instead of the minor version to 2.

Hakan Özler · Answer 31 · Fri Dec 30 2022 20:07:55 GMT+0800 (China Standard Time)

Hi @valtsmazurs , I see the point, let me upgrade the version to 4.0.0 that would be more practical based on your advise. Thank you.

Rob · Answer 32 · Thu Jan 05 2023 01:14:38 GMT+0800 (China Standard Time)

Thanks for getting this through @ozlerhakan, especially over the holiday period.
Apologies, I hadn't seen your other messages, but thanks for supporting this.