[ 
https://issues.apache.org/jira/browse/NIFI-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15941343#comment-15941343
 ] 

ASF GitHub Bot commented on NIFI-3413:
--------------------------------------

Github user phrocker commented on the issue:

    https://github.com/apache/nifi/pull/1618
  
    @mattyb149  Cool stuff. I used your template because it was an easier place 
to start. Seems pretty good. I'll continue to test at my leisure but I'm happy 
with it presently. I tried to break it by stopping mysql mid cycle and 
BinaryLogClient handled it gracefully and all was well. Besides the NPE above 
I'm happy thus far. I'll continue to play with it for my own edification. Let 
me know if you wish me to test the NPE again or not. 


> Implement a GetChangeDataCapture processor
> ------------------------------------------
>
>                 Key: NIFI-3413
>                 URL: https://issues.apache.org/jira/browse/NIFI-3413
>             Project: Apache NiFi
>          Issue Type: New Feature
>          Components: Extensions
>            Reporter: Matt Burgess
>            Assignee: Matt Burgess
>
> Database systems such as MySQL, Oracle, and SQL Server allow access to their 
> transactional logs and such, in order for external clients to have a "change 
> data capture" (CDC) capability. I propose a GetChangeDataCapture processor to 
> enable this in NiFi.
> The processor would be configured with a DBCPConnectionPool controller 
> service, as well as a Database Type property (similar to the one in 
> QueryDatabaseTable) for database-specific handling. Additional properties 
> might include the CDC table name, etc.  Additional database-specific 
> properties could be handled using dynamic properties (and the documentation 
> should reflect this).
> The processor would accept no incoming connections (it is a "Get" or source 
> processor), would be intended to run on the primary node only as a single 
> threaded processor, and would generate a flow file for each operation 
> (INSERT, UPDATE, DELETE, e,g,) in one or some number of formats (JSON, e.g.). 
> The flow files would be transferred in time order (to enable a replication 
> solution, for example), perhaps with some auto-incrementing attribute to also 
> indicate order if need be.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to