[ 
https://issues.apache.org/jira/browse/CSV-253?focusedWorklogId=523374&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-523374
 ]

ASF GitHub Bot logged work on CSV-253:
--------------------------------------

                Author: ASF GitHub Bot
            Created on: 12/Dec/20 07:00
            Start Date: 12/Dec/20 07:00
    Worklog Time Spent: 10m 
      Work Description: lbruun commented on pull request #51:
URL: https://github.com/apache/commons-csv/pull/51#issuecomment-743715066


   @divijvaidya. The PR is what it is and is complete. However, since time has 
now passed the PR now has a minor merge conflict. Also my changes to Javadoc 
states (for this new feature) "since 1.8" which seemed reasonable at the time 
because it was the the (then) upcoming release and I was hoping the maintainers 
would include my PR for that release. Version 1.8 has since then been released 
_without_ this PR so that would need to be changed in the PR.
   
   Anyway, my main problem is that I haven't been able to explain to 
maintainers of this library why this is a missing feature in the library. In 
short why the library should be able to distinguish between (when parsing):
   
   ```text
   545-03-1234,"","Doe"
   ```
   
   and 
   ```text
   545-03-1234,,"Doe"
   ```
   
   ..and why the existing feature, 
`org.apache.commons.csv.CSVFormat.nullString`, doesn't address this problem. 
You can see the explanation and discussion 
[here](https://issues.apache.org/jira/browse/CSV-253?focusedCommentId=16962105&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16962105).
   
   Note that once maintainer(s) of the library agree to the problem being 
present then the next discussion is obviously _how_ to address it. My 
suggestion in this PR favors strict backwards compatibility (no breaking 
change) : I simply introduce a new attribute rather than changing what the 
existing attribute `nullString` does. This will probably be confusing for users 
of the library, but the alternative - breaking change - is worse IMHO.
   
   I'll be glad to update the PR if I thought it had chance of being accepted.
   
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
[email protected]


Issue Time Tracking
-------------------

    Worklog Id:     (was: 523374)
    Time Spent: 50m  (was: 40m)

> Handle absent values in input (null)
> ------------------------------------
>
>                 Key: CSV-253
>                 URL: https://issues.apache.org/jira/browse/CSV-253
>             Project: Commons CSV
>          Issue Type: Improvement
>          Components: Parser
>            Reporter: Lars Bruun-Hansen
>            Priority: Major
>         Attachments: 2019-10-30 20_31_39-Apache Commons CSV 1.8-SNAPSHOT 
> API.png, Parser-setting-absentIsNull-Javadoc.png
>
>          Time Spent: 50m
>  Remaining Estimate: 0h
>
> The parser must be able to handle absent values in input and translate that 
> into {{null}} as required. I see several tickets on this matter in the 
> history, but none seem to have addressed the issue, at least not for parsing. 
> For this problem, I see a need to introduce a new term:
> Definition: _Absent value_ is when there are zero characters between field 
> delimiters.
> Specifically the aim is to be able to parse the following:
> {noformat}
>     "John",,"Doe"    // 2nd element is absent
>     ,"AA",123        // 1st element is absent
>     "John",90,       // 3rd element is absent
>     "",,90           // 2nd element is absent (1st element isn't)
> {noformat}
>  
> See also CSV-93 which I think never addressed the issue, probably because the 
> reporter was happy with having the issue fixed for CSV output, not for 
> parsing.
> A PR is coming...



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to