Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 3E5E6200CF0 for ; Thu, 7 Sep 2017 17:14:19 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 3E32D160D30; Thu, 7 Sep 2017 15:14:19 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 872CF16105A for ; Thu, 7 Sep 2017 17:14:18 +0200 (CEST) Received: (qmail 79251 invoked by uid 500); 7 Sep 2017 15:14:17 -0000 Mailing-List: contact issues-help@nifi.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@nifi.apache.org Delivered-To: mailing list issues@nifi.apache.org Received: (qmail 79242 invoked by uid 99); 7 Sep 2017 15:14:17 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Sep 2017 15:14:17 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 22A92C3F06 for ; Thu, 7 Sep 2017 15:14:17 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id ljwXjhun-f5T for ; Thu, 7 Sep 2017 15:14:12 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id E151C61044 for ; Thu, 7 Sep 2017 15:14:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 2C80AE06CF for ; Thu, 7 Sep 2017 15:14:01 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 532E92414B for ; Thu, 7 Sep 2017 15:14:00 +0000 (UTC) Date: Thu, 7 Sep 2017 15:14:00 +0000 (UTC) From: "ASF GitHub Bot (JIRA)" To: issues@nifi.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (NIFI-3484) GenerateTableFetch Should Allow for Right Boundary MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 07 Sep 2017 15:14:19 -0000 [ https://issues.apache.org/jira/browse/NIFI-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16157059#comment-16157059 ] ASF GitHub Bot commented on NIFI-3484: -------------------------------------- Github user mattyb149 commented on the issue: https://github.com/apache/nifi/pull/2091 +1 LGTM, built and ran unit tests, also verified the correct behavior on MySQL, Oracle 11, and Postgres DBs. Thanks for the improvement! Merging to master > GenerateTableFetch Should Allow for Right Boundary > -------------------------------------------------- > > Key: NIFI-3484 > URL: https://issues.apache.org/jira/browse/NIFI-3484 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework > Affects Versions: 1.2.0 > Reporter: Peter Wicks > Assignee: Peter Wicks > Priority: Minor > Fix For: 1.4.0 > > > When using GenerateTableFetch it places no right hand boundary on pages of data. This can lead to issues when the statement says to get the next 1000 records greater then a specific key, but records were added to the table between the time the processor executed and when the SQL is being executed. As a result it pulls in records that did not exist when the processor was run. On the next execution of the processor these records will be pulled in a second time. > Example: > Partition Size = 1000 > First run (no state): Count(*)=4700 and MAX(ID)=4700. > 5 FlowFiles are generated, the last one will say to fetch 1000, not 700. (But I don't think this is really a bug, just an observation). > 5 Flow Files are now in queue to be executed by ExecuteSQL. Before the 5th file can execute 400 new rows are added to the table. When the final SQL statement is executed 300 extra records, with higher ID values, will also be pulled into NiFi. > Second run (state: ID=4700). Count(*) ID>4700 = 400 and MAX(ID)=5100. > 1 Flow File is generated, but includes 300 records already pulled into NiFI. > The solution is to have an optional property that will let users use the new MAX(ID) as a right boundary when generating queries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)