[
https://issues.apache.org/jira/browse/NIFI-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706978#comment-14706978
]
Dan Bress commented on NIFI-293:
--------------------------------
_What do you propose is a good solution at this stage? _
If we plan to expand ExecuteSQL to include insert/update/delete statements,
then I see no need to change anything... Although at that point I don't know
why we would need PutSQL also. I know that its probably very tricky to solve
all of the problems you bring up(returning scalar quantities vs ResultSets)
right from the get go, and am OK with them being solved incrementally if that's
the plan.
If ExecuteSQL is 'done' and we don't want insert/update/delete, I would propose
we mark this class as @Deprecated, and copy it and called it SelectSQL and that
becomes the 'living thing' moving forward. I would make sure NIFI-391 is
resolved before we do that though.
I am aware that I am fully coming from the perspective of _make it right and
consistent_ and not very much from _don't break your existing users_. The
latter is a new perspective for me, but i trust that your experience on that
matter will help get us where we need to be.
> 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)
