Paul: I can apply the fix from hbase-2037... I can break it out of the posted patch thats up there. Just say the word.
St.Ack On Tue, Dec 15, 2009 at 4:17 PM, Ram Kulbak <ram.kul...@gmail.com> wrote: > Hi Paul, > > I've encountered the same problem. I think its fixed as part of > https://issues.apache.org/jira/browse/HBASE-2037 > > Regards, > Yoram > > > > On Wed, Dec 16, 2009 at 10:45 AM, Paul Ambrose <pambr...@mac.com> wrote: > > > I ran into some problems with FilterList and SingleColumnValueFilter. > > > > I created a FilterList with MUST_PASS_ONE and two > SingleColumnValueFilters > > (each testing equality on a different columns) and query some trivial > data: > > > > http://pastie.org/744890 > > > > The problem that I encountered were two-fold: > > > > SingleColumnValueFilter.filterKeyValues() returns ReturnCode.INCLUDE > > if the column names do not match. If FilterList is employed, then when > the > > first Filter returns INCLUDE (because the column names do not match), no > > more filters for that KeyValue are evaluated. That is problematic > because > > when filterRow() is finally called for those filters, matchedColumn is > > never > > found to be true because they were not invoked (due to FilterList exiting > > from > > the filterList iteration when the name mismatched INCLUDE was returned). > > The fix (at least for this scenario) is for > > SingleColumnValueFilter.filterKeyValues() to > > return ReturnCode.NEXT_ROW (rather than INCLUDE). > > > > The second problem is at the bottom of FilterList.filterKeyValue() > > where ReturnCode.SKIP is returned if MUST_PASS_ONE is the operator, > > rather than always returning ReturnCode.INCLUDE and then leaving the > > final filter decision to be made by the call to filterRow(). I am sure > > there is a good > > reason for returning SKIP in other scenarios, but it is problematic in > > mine. > > > > Feedback would be much appreciated. > > > > Paul > > > > > > > > > > > > > > > > >
