[
https://issues.apache.org/jira/browse/CRUNCH-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13552853#comment-13552853
]
Dave Beech edited comment on CRUNCH-142 at 1/14/13 4:36 PM:
------------------------------------------------------------
I can see the problem and you're right, there's no clear right thing for AndFn
to do in its cleanup method. But on the other hand I'm not sure it's relevant.
The main problem for me is if you allow users to override methods, but then
silently fail to run their code under certain cases.
I think these two lines should be functionally equivalent:
PCollection<?> filtered1 = collection.filter(fnA).filter(fnB);
PCollection<?> filtered2 = collection.filter(FilterFns.and(fnA, fnB));
But, without a delegating call to cleanup in AndFn, depending on what I'd put
in my cleanup overrides, I might get different results.
How about an unconditional call to cleanup on all the child FilterFns,
regardless of whether they were a part of an And, Or or Not. If the user
decides to emit a ton of stuff in cleanup which violates the filter logic, then
that may be bad form but surely that's their decision?
was (Author: dbeech):
I can see the problem and you're right, there's no clear right thing for
AndFn to do in its cleanup method. But on the other hand I'm not sure it's
relevant. The main problem for me is if you allow users to override methods,
but then silently fail to run their code under certain cases.
I think these two lines should be functionally equivalent:
PCollection<?> filtered1 = collection.filter(fnA).filter(fnB);
PCollection<?> filtered2 = collection.filter(FilterFns.and(fnA, fnB));
But, without a delegating call to cleanup in AndFn, depending on what I'd put
in the my cleanup overrides, I might get different results.
How about an unconditional call to cleanup on all the child FilterFns,
regardless of whether they were a part of an And, Or or Not. If the user
decides to emit a ton of stuff in cleanup which violates the filter logic, then
that may be bad form but surely that's their decision?
> Context not being passed to FilterFn instances wrapped in boolean
> AndFn,OrFn,NotFn
> ----------------------------------------------------------------------------------
>
> Key: CRUNCH-142
> URL: https://issues.apache.org/jira/browse/CRUNCH-142
> Project: Crunch
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.4.0
> Reporter: Dave Beech
> Assignee: Gabriel Reid
> Fix For: 0.5.0
>
> Attachments: CRUNCH-142_1.patch, CRUNCH-142_2.patch, CRUNCH-142.patch
>
>
> The boolean filter classes AndFn, OrFn and NotFn delegate calls to FilterFn
> instances internally, but setContext is not called on these first.
> As a result, methods which need the context such as getCounter() fail with
> NullPointerException.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
