[
https://issues.apache.org/jira/browse/NIFI-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14307458#comment-14307458
]
Mark Payne commented on NIFI-293:
---------------------------------
Ricky,
I think that's very reasonable. I would think we would want to allow for both
approaches, using a PreparedStatement or just using the way provided... i would
just worry about SQL Injection attacks. Especially if the attributes are
generated from HTTP Headers for instance...
A better approach may be actually to use the AttributeDecorator when we
evaluate the Expression Language. I.e., evaluate the expression language by
calling: evaluateAttributeExpressions(FlowFile flowFile,
AttributeValueDecorator decorator)
The AttributeValueDecorator is a simple interface that allows us to change the
value returned... so within there we could escape the values. This way, we can
allow the user to enter text like you suggested and still protect from SQL
Injection attacks.
> 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
>
> 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)
