Re: IO IT Patterns: Simplifying data loading

2017-03-29 Thread Stephen Sisk
Hey Cham, Debugging is harder I definitely agree. As I said (and I think you still generally agree), I think the tradeoff is worth it. Looking at the data store in question can quickly narrow it down to one vs the other for a particular failure. Eventually consistent data stores

Re: IO IT Patterns: Simplifying data loading

2017-03-28 Thread Chamikara Jayalath
On Tue, Mar 28, 2017 at 3:00 AM Etienne Chauchot wrote: > Hi Stephen, > > I have some comments bellow: > > > Le 24/03/2017 à 00:26, Stephen Sisk a écrit : > > hi! > > > > I just opened a jira ticket that I wanted to make sure the mailing list > got > > a chance to see. > > >

Re: IO IT Patterns: Simplifying data loading

2017-03-28 Thread Stephen Sisk
Hey Etienne, I was hoping you'd get a chance to weigh in on this. "But this does the assumption of the order of test runs: write test needs to have been run before read test can happen. Maybe a little dangerous to do this assumption no?" I actually avoid this in the JdbcIOIT example [1] by

Re: IO IT Patterns: Simplifying data loading

2017-03-23 Thread Stephen Sisk
thanks, appreciated :) On Thu, Mar 23, 2017 at 4:59 PM Ted Yu wrote: > Looks like you forgot to include JIRA number: BEAM-1799 > > Cheers > > On Thu, Mar 23, 2017 at 4:26 PM, Stephen Sisk > wrote: > > > hi! > > > > I just opened a jira ticket that

IO IT Patterns: Simplifying data loading

2017-03-23 Thread Stephen Sisk
hi! I just opened a jira ticket that I wanted to make sure the mailing list got a chance to see. The problem is that the current design pattern for doing data loading in IO ITs (either writing a small program or using an external tool) is complex, inefficient and requires extra steps like