lbruun edited a comment on pull request #51:
URL: https://github.com/apache/commons-csv/pull/51#issuecomment-744287248


   @garydgregory I think what you are essentially saying is to do [PR 
77](https://github.com/apache/commons-csv/pull/77) rather than this one. Either 
way will work.
   
   It is all about the appetite for breaking changes (PR77) vs a new opt-in 
feature (this PR). On one hand you can argue that the library should have been 
able to distinguish between empty string and absent string from the very 
beginning and therefore fixing it by changing existing behavior is justified, 
meaning do PR77. But in the world of CSV only a single generally agreed-upon 
standard exists, RFC4180, and that one is inconclusive about this scenario. We 
also have the [W3's Recommendation for Tabular 
Data](https://www.w3.org/TR/tabular-data-model/) but that one actually clearly 
states that the empty string and absent string are the same. This speaks 
towards that the way the library currently works should be the default and 
therefore that a breaking change it not acceptable.
   
   Example: Let's say a user is currently using static format `POSTGRESQL_CSV` 
to parse output which originates from a PostgreSQL database. Such user will 
with PR77 potentially start to see NPEs just because he updated to latest 
version of Apache Commons CSV. Ouch!
   
   However, what speaks in favor of a breaking change, meaning PR77, is that 
most users will possibly (unfairly?) expect a CSV format to be _lossless_, 
meaning that if they export from their database into CSV and then re-import 
that CSV file into same database then no data has been lost or distorted. With 
PR77 you uphold the principle of lossless conversion and if this is what users 
implicitly expect from the library then PR77 is the way to go.
   
   Personally I'm leaning towards PR77, even if it is a breaking change. It 
just needs clear documentation, 
   


----------------------------------------------------------------
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]


Reply via email to