[
https://issues.apache.org/jira/browse/NIFI-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16336746#comment-16336746
]
Peter Wicks commented on NIFI-1706:
-----------------------------------
[~ijokarumawak] I've written many views for use with QueryDatabaseTable, and
it's my preferred approach.
The use case for allowing custom SQL is more about permissions. In some cases I
have read-only permission to the server/database, and the group that owns the
system is not willing to allow me to create views; generally it's a combination
of they don't have time to support me + every other team that writes reports
(MS SQL Reporting Services, Tableau, etc...) is successful with their currently
structure, so why can't I be?
There are alternatives to adding this functionality to QueryDatabaseTable:
* Create a brand new processor that is a cross between QueryDatabaseTable and
ExecuteSQL
* Extend ExecuteSQL to include optional state tracking features. It could be a
more manual process where users have to provide initial max values and then
insert the max values into the query by hand using EL.
> Extend QueryDatabaseTable to support arbitrary queries
> ------------------------------------------------------
>
> Key: NIFI-1706
> URL: https://issues.apache.org/jira/browse/NIFI-1706
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Affects Versions: 1.4.0
> Reporter: Paul Bormans
> Assignee: Peter Wicks
> Priority: Major
> Labels: features
>
> The QueryDatabaseTable is able to observe a configured database table for new
> rows and yield these into the flowfile. The model of an rdbms however is
> often (if not always) normalized so you would need to join various tables in
> order to "flatten" the data into useful events for a processing pipeline as
> can be build with nifi or various tools within the hadoop ecosystem.
> The request is to extend the processor to specify an arbitrary sql query
> instead of specifying the table name + columns.
> In addition (this may be another issue?) it is desired to limit the number of
> rows returned per run. Not just because of bandwidth issue's from the nifi
> pipeline onwards but mainly because huge databases may not be able to return
> so many records within a reasonable time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
