Re: JDBC Poller implementation

+1 for common abstract class and specific implementations that are use case specific. Regards, Ashwin. On Mon, Aug 8, 2016 at 7:55 AM, Devendra Tagare wrote: > + 1 for a common Abstract Class. > > 0 - for adding ports. > > Use-case for CSV - data migration from

Re: JDBC Poller implementation

+ 1 for a common Abstract Class. 0 - for adding ports. Use-case for CSV - data migration from columnar stores.Some users may want to move TB's of data from a store like Greenplum and then do transformations using the CSV parser that is already present. Thanks, Dev On Mon, Aug 8, 2016 at 7:39

Re: JDBC Poller implementation

+1 for Tushar's idea for common abstract class. Additionally, POJO based output should be considered for active development. CSV output can be deprecated. Since it can be achieved easily using POJO + CSV formatter. Operators are meant to be lego blocks for reusable functionality to achieve

Re: JDBC Poller implementation

I would prefer a common abstract class having emitTuple method. And two different implementation one for emitting comma separated values and other emitting pojo. Regards, -Tushar. On Mon, Aug 8, 2016 at 5:34 PM, Priyanka Gugale wrote: > The concrete implementation is

Re: JDBC Poller implementation

The concrete implementation is supposed to do mainly formatting of input data and emit in required form. Also it would be tricky to implement some abstract methods like "getTuple", you have to conditionally return the values. -Priyanka On Mon, Aug 8, 2016 at 4:49 PM, Bhupesh Chawda

Re: JDBC Poller implementation

I am +1 for having two ports in the same concrete implementation. One port for POJOs and second one for CSV strings (if this is actually needed) +0 on having multiple concrete operators. I don't think it is necessary to create multiple concrete implementations just because we want the same data