Hello That processor has changed only once since March 2021 (when 1.13.2 came out). That was this commit [1] for this JIRA [2].
>From a quick look it isn't obvious to me how that could be related. Mattyb/MarkP any thoughts? [1] https://github.com/apache/nifi/commit/ecacfdaa4c663ff2831dd13a840aabd0ff3349e8#diff-a48356fe90b0a91edd4052725aede89bb5ccd75877d37a3d6d6ec08ce2ff0dc2 [2] https://issues.apache.org/jira/browse/NIFI-8469 Thanks Joe On Fri, Jan 14, 2022 at 8:43 AM Hendrik Ruijter <[email protected]> wrote: > > Hello, in GenerateTableFetch 1.15.0, I use the dynamic property > initial.maxvalue.<max_value_column> when I move timestamp state to a new > cluster from old GenerateTableFetch 1.13.2 processors. > > > > First use case: > > SQL Server > > initial.maxvalue.tm > > 1326581088 > > > > State is set correctly to 1326581088 and the flowfile is terminated by > GenerateTableFetch 1.15.0. > > > > Second use case: > > MySQL Server > > initial.maxvalue.time > > 2022-01-14 06:13:57.0 > > > > State is set correctly to Now() UTC (not to the dynamic property 2022-01-14 > 06:13:57.0) and the flowfile contains a correct select statement with a where > clause to execute. > > > > Is the expected behavior to terminate the flowfile when the state is set as > in the first use case? > > Or, is the expected behavior to set the state and execute the generated > select statement as in second use case? > > > > Sorry, I am unable to find the answer in the documentation and my Java source > code knowledge is very limited.
