[ 
https://issues.apache.org/jira/browse/NIFI-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16147849#comment-16147849
 ] 

ASF GitHub Bot commented on NIFI-4242:
--------------------------------------

Github user markap14 commented on a diff in the pull request:

    https://github.com/apache/nifi/pull/2088#discussion_r136160691
  
    --- Diff: 
nifi-mock/src/main/java/org/apache/nifi/util/MockConfigurationContext.java ---
    @@ -58,8 +58,12 @@ public MockConfigurationContext(final ControllerService 
service,
     
         @Override
         public PropertyValue getProperty(final PropertyDescriptor property) {
    -        String value = properties.get(property);
    --- End diff --
    
    @Wesley-Lawrence I don't think this is really what we want here. The 
concept of a default value is 'use this if the value is null'. So changing this 
would be inconsistent with how the StandardProcessContext works as well. I 
think the more desirable approach would be to just update the 
SingleCharacterValidator being used such that we allow 0 or 1 character. Then, 
this would allow an empty string to be used as the delimiter, which I believe 
is equivalent.


> CSVReader shouldn't require that an escape character be defined
> ---------------------------------------------------------------
>
>                 Key: NIFI-4242
>                 URL: https://issues.apache.org/jira/browse/NIFI-4242
>             Project: Apache NiFi
>          Issue Type: Bug
>    Affects Versions: 1.3.0
>            Reporter: Wesley L Lawrence
>            Priority: Minor
>         Attachments: NIFI-4242.patch, NIFI-4242.patch
>
>
> There are situations where, when parsing a CSV file, one doesn't want to 
> define an escape character. For example, when using quote character ", the 
> following is valid CSV;
> {code}
> a,"""b",c
> {code}
> The second column should be interpreted as "b. But when Apache Commons CSV is 
> told that there's an escape character, the above row is invalid 
> (interestingly, if it was """b""", it would be valid as "b"). 
> There are known formats that Apache Commons CSV provides, that doesn't define 
> escape characters either.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to