[
https://issues.apache.org/jira/browse/CSV-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888117#comment-17888117
]
Mikhail T. edited comment on CSV-313 at 10/10/24 3:07 AM:
----------------------------------------------------------
Thanks, [~ggregory], for the quick reaction.
{quote}The patch breaks the build; you can see by running "mvn" from the
command line.
{quote}
I don't see this. Of course, I did {{mvn test}} before submitting the patch,
and it succeeds with both JDK8 and JDK17:
{noformat}
...
[INFO] Results:
[INFO]
[WARNING] Tests run: 856, Failures: 0, Errors: 0, Skipped: 11
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
{noformat}
Perhaps, you tried it in some other branch, not the {{{}master{}}}?
{quote}You cannot change the return value of this public method as it would
break binary compatibility.
{quote}
Yes, indeed... I didn't realize, this would be a problem, when just the
return-type (rather than arguments) are changing. I don't know, how to do this
elegantly then – adding some new {{{}printRecordsWithTotal(){}}}? (Attached
[^printRecords.patch.txt] for now...)
{quote}Using a GitHub PR is the best way to propose code changes as running a
PR build runs all of our checks.
{quote}
Then, perhaps, an attempt to submit a patch should be directing people to
GitHub automatically? Why even bother with your own Jira-instance, if GitHub is
used anyway?
{quote}You'll also want to provide unit tests to prove a patch does what it
thinks it does.
{quote}
I was hoping, someone else would help with this – my home machine has no
database-servers within reach, so obtaining a meaningful {{ResultSet}} would be
hard.
But the idea is simple, even if my patch is imperfect, it should not take a
current team-member long to implement it following the team's practices,
customs, and traditions.
was (Author: JIRAUSER307341):
Thanks, [~ggregory], for the quick reaction.
bq. The patch breaks the build; you can see by running "mvn" from the command
line.
I don't see this. Of course, I did {{mvn test}} before submitting the patch,
and it succeeds with both JDK8 and JDK17:{noformat}...
[INFO] Results:
[INFO]
[WARNING] Tests run: 856, Failures: 0, Errors: 0, Skipped: 11
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
{noformat}
Perhaps, you tried it in some other branch, not the {{master}}?
bq. You cannot change the return value of this public method as it would break
binary compatibility.
Yes, indeed... I didn't realize, this would be a problem, when just the
return-type (rather than arguments) are changing. I don't know, how to do this
elegantly then -- adding some new {{printRecordsWithTotal()}}?
bq. Using a GitHub PR is the best way to propose code changes as running a PR
build runs all of our checks.
Then, perhaps, an attempt to submit a patch should be directing people to
GitHub automatically? Why even bother with your own Jira-instance, if GitHub is
used anyway?
bq. You'll also want to provide unit tests to prove a patch does what it thinks
it does.
I was hoping, someone else would help with this -- my home machine has no
database-servers within reach, so obtaining a meaningful {{ResultSet}} would be
hard.
> No way to obtain the number of rows written by CSVPrinter's printRecords()
> --------------------------------------------------------------------------
>
> Key: CSV-313
> URL: https://issues.apache.org/jira/browse/CSV-313
> Project: Commons CSV
> Issue Type: Improvement
> Components: Printer
> Reporter: Mikhail T.
> Priority: Minor
> Labels: easyfix
> Attachments: printRecords.patch.txt
>
>
> The {{printRecords(ResultSet)}} variant is very convenient for outputting
> _all_ of a query's results in a single line of code.
> Unfortunately, this provides no way to obtain the number of records printed.
> See [this StackOverflow
> question|https://stackoverflow.com/questions/79071049/], for example.
> A forward-only result-set is "done" after the method returns...
> The simplest way to address this shortcoming would be for the
> {{printRecords()}} to start returning a {{long}} (for lack of {{{}size_t{}}})
> instead of {{{}void{}}}, indicating the number of records printed.
> This seems like an easy fix, for certainly the number of output rows is
> _known_ inside the method...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
