[
https://issues.apache.org/jira/browse/NIFI-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14658198#comment-14658198
]
Mark Payne commented on NIFI-293:
---------------------------------
I've been thinking about what makes sense in the realm of JDBC processors to
insert/update rows in a database. I think a nice approach to take, in addition
to what [~Toivo Adams] has already provided, would be a Processor that reads an
arbitrary SQL statement from a FlowFile's content. Or perhaps this would be a
modification to the ExecuteSQL processor that exists currently.
The benefit to doing it this way is that if we have incoming JSON, for
instance, we can have a processor convert that JSON into a SQL statement. If we
have Avro, we can have a processor convert the Avro into SQL. If we have any
sort of data format, really, we can have a processor that converts that data
format into a SQL statement. This allows the SQL processor to focus only on
interacting with the database and not have to worry about all of the different
potential data formats. This results in a much simpler & cleaner processor and
is also far more flexible, as it means that we can configure the conversion
processors very differently, depending on the data types.
> Add a JDBC Processor for executing arbitrary SQL queries
> --------------------------------------------------------
>
> Key: NIFI-293
> URL: https://issues.apache.org/jira/browse/NIFI-293
> Project: Apache NiFi
> Issue Type: New Feature
> Reporter: Ricky Saltzer
> Attachments: AvroWriter.java
>
>
> This could be very useful for a variety of tasks, such as updating a value in
> a PostgreSQL table, or adding a new partition to Hive.
> Ideally, SQL commands could be generated using the NiFi expression language
> using FlowFile attributes.
> The processor should as generic as possible so that any of the popular JDBC
> drivers can be used (e.g. PostgreSQL, Hive, Impala).
> I'm still new to how processors are architected, but it seems that using a
> pre-defined service in the _services.xml_ file (like the distributed map
> cache) would be the most efficient way to share a connection pool across
> multiple JDBC processors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
