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

Aldrin Piri commented on NIFI-853:
----------------------------------

Makes a lot of sense and am a big fan of the idea to make better use of our 
commands.  

The one item that is a little "scary" is how we fix/handle items that are bad 
tenants of their destination table.  If I have a record as part of that batch 
update and it perhaps violates some constraint such that it is rejected, how 
can I move past that point in NiFi and handle an appropriate course of 
mediation afterward?

At this point, does it not come down to DB specific handling of batches?  

Not sure if these are well solved problems or not.  Admittedly my SQL skills 
are not quite what they used.

> Create Processors to put JSON data to a Relational Database
> -----------------------------------------------------------
>
>                 Key: NIFI-853
>                 URL: https://issues.apache.org/jira/browse/NIFI-853
>             Project: Apache NiFi
>          Issue Type: Task
>          Components: Extensions
>            Reporter: Mark Payne
>            Assignee: Mark Payne
>             Fix For: 0.3.0
>
>         Attachments: 
> 0001-NIFI-853-Added-processors-ConvertFlatJSONToSQL-PutSQ.patch, 
> 0002-NIFI-853-Made-updates-to-processors.patch
>
>
> Most of the discussion/design for these processors happened in the comments 
> of NIFI-293, which was the initial ticket for implementing JDBC functionality 
> in NiFi, but was closed in a previous version, so this ticket was created to 
> do the work.
> The idea is to have a processor that will take in FlowFiles whose contents 
> are arbitrary SQL INSERT/UPDATE commands. The commands can be parameterized 
> with the parameters' values and types in FlowFile attributes.
> We then should have a processor that converts a JSON document into a SQL 
> command to either update or insert data into a database table. We will also 
> want some other processors in the future probably to handle other data types, 
> such as converting XML, CSV, Avro, etc. into SQL commands.
> This breakout gives us a nice coherence to the "do only one thing and do it 
> well" principle by separating the logic of handling all of the incoming 
> formats from the logic of updating the database.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to