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

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

Github user patricker commented on the issue:

    https://github.com/apache/nifi/pull/2424
  
    @ijokarumawak I think column names/table names should be kept unwrapped in 
all locations, and wrapped as needed by the Database Adapter.  This will allow 
all columns to be stored uniformly no matter which adapter is used. Also in 
cases like `initial.maxvalue` property use, the user won't need to worry about 
wrapping the column name.


> AbstractDatabaseFetchProcessor handles SQL Server brackets incorrectly
> ----------------------------------------------------------------------
>
>                 Key: NIFI-4393
>                 URL: https://issues.apache.org/jira/browse/NIFI-4393
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Extensions
>    Affects Versions: 1.4.0
>            Reporter: MikoĊ‚aj Siedlarek
>            Assignee: Koji Kawamura
>            Priority: Major
>         Attachments: 
> 0001-Handle-SQL-Server-square-brackets-in-AbstractDatabas.patch
>
>
> SQL Server allows column names to contain whitespace, in which case they are 
> written in SQL queries inside square brackets. When using processors based on 
> {{AbstractDatabaseFetchProcessor}}, such as {{QueryDatabaseTable}} they have 
> to be specified in  "Maximum-value Columns" in square brackets, because 
> otherwise they would break a SELECT query. However, when such column name is 
> retrieved from ResultSetMetaData, the driver returns it without square 
> brackets. This causes a mismatch between the key used to save last seen 
> maximum value in processor's state and the one used to search for the value 
> later.
> I'm not sure whether the attached patch is very elegant, but it fixes the 
> issue in a simplest way possible.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to