@Vlad I agree with your suggestion to have StringFileOutput default to empty.
-1 for the separate operator to add delimiter. Agreed that composition is nice design. But, decomposing the functionality into too many tiny pieces would lead to extra composition overhead by the app developer which can be avoided by having the right balance. For CSV to JDBC usecase, we have tupleseperator configurable. It can be set to empty string for this case. ~ Yogi On 13 August 2016 at 08:39, Vlad Rozov <[email protected]> wrote: > StringFileOutput should default to empty. It should be possible to send > multiple strings to a file without every new string being on a new line. > > Possibly a better option will be to have a separate operator that inserts > necessary delimiters as csvformatter may be connected to jdbc output > operator and should not insert new lines after each tuple. That brings > overall design question: is it better to compose dag from multiple > operators or overload each operator functionality with extra features. IMO, > composition is better. > > Thank you, > Vlad > > Отправлено с iPhone > > > On Aug 12, 2016, at 19:09, Venkatesh Kottapalli < > [email protected]> wrote: > > > > > > IMO, since we have an option to configure the line delimiter, leaving it > to the user is a good idea as there might be cases where either one of them > is used and not both. > > > > -Venkatesh. > > > > > >> On Aug 12, 2016, at 6:29 PM, Yogi Devendra <[email protected]> > wrote: > >> > >> Hi, > >> > >> Currently, for the usecases involving writing POJO to file output we use > >> DAG simillar to following: > >> POJOEmittingOperator->CSVFormatter->StringFileOutputOperator. > >> > >> Both CSVFormatter as well as StringFileOutputOperator have > >> configurable tupleSeperator defaulting to newline. This introduces two > >> newlines for every tuple. We should make one of the defaults to empty > >> string and the other to be newline. > >> > >> Any opinions on which default should be empty string? > >> > >> ~ Yogi > > >
