Yeah, this sounds really nice. It also seems to let runners do "whatever they want" -- write to files, switch to some magic but small-scale state, etc.
On Thu, Mar 30, 2017 at 10:50 PM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Pablo, > > it sounds a good idea ! > > Regards > JB > > > On 03/31/2017 12:12 AM, Pablo Estrada wrote: > >> Hello all, >> >> BEAM-775 aims to remove Aggregators from the Java SDK. One of the blocking >> issues is BEAM-1148, porting PAssert away from using them. Let me >> summarize >> the issues that we should consider; and then propose a solution that seems >> reasonable: >> >> 1. We want the test Pipeline run to fail-fast in the case of a failed >> assertion. >> 2. We want the test Pipeline run to fail if not all of the assertions were >> executed. This catches bugs that would otherwise be hidden. >> 3. We want to provide a simple default implementation for PAssert. Metrics >> are not supported by all runners and when they are both of >> committed/attempted values may not be available.ut they seem like a >> reasonable default mechanism to count success/failure of assertions. >> >> With this in mind, I propose the following: >> 1. The mechanism to count/check assertions will be a composite PTransform >> that receives the results from the PAssert transforms. Test runners will >> be >> able to override the implementiation of this PTransform. >> >> * The current asserting DoFns in PAssert will go from being DoFn<ActualT, >> Void> to be DoFn<ActualT, SuccesOrFailure>, and pass the output >> SuccessOrFailure objects downstream to the checking >> PTransform<SuccessOrFailure, Void>. >> * This default PTransform<SuccessOrFailure, Void> will use metrics to >> count >> successes, and fail immediately on failures (after incrementing the >> failure >> counter). >> >> 2. A test runner can override the default implementations of this >> PTransform using the graph surgery API. >> >> 3. Every TestXRunner implements its own PAssert verification, so we may >> need to change that individually - though these changes are not likely to >> be very significant for the existing runners. >> >> What are your thoughts? >> If everyone is okay with this proposed idea, I will go ahead and implement >> it. >> Best >> -P. >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
