[
https://issues.apache.org/jira/browse/NIFI-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14705779#comment-14705779
]
Mark Payne commented on NIFI-293:
---------------------------------
Dan,
Yes, the difference is that PutSQL handles DML commands (INSERT, DELETE,
UPDATE), while ExecuteSQL handles SELECT statements. These
are different components because the result that is returned by INSERT, DELETE,
UPDATE is essentially an integer, while the results returned
from ExecuteSQL are rows of data.
SelectSQL would have perhaps been a better name, but the convention for Get*
Processors is generally that they will be the first Processor
in a flow (i.e., will take no input). At this point, though, since ExecuteSQL
has already been released and in use, I'm not sure that we can
really rename it because doing so would result in flows becoming invalid when
upgrading to the new version.
We could perhaps consider a mechanism that would allow a Processor's "Type" to
be changed, rather than based solely on the name of
the class, similar to the way that a PropertyDescriptor can have a "Display
Name". Thoughts?
----------------------------------------
> 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)
